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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

The present document is part 6 sub-part 1, of a multi-part deliverable covering Broadcast and On-line Services: Search, 
select and rightful use of content on personal storage systems ("TV-Anytime Phase 1"), as identified below: 

Part 1: "Phase 1 Benchmark Features"; 

Part 2: "System description"; 

Part 3: "Metadata"; 

Part 4: "Content referencing" ; 

Part 5: Not currently applicable in TV-Anytime Phase 1; 

Part 6: "Delivery of metadata over a bi-directional network"; 

Sub-part 1: "Service and transport"; 

Sub-part 2: "Service discovery"; 
Part 7 : "Bi-directional metadata delivery protection" . 



Introduction 

The present document is based on a submission by the TV-Anytime forum ( http://www.TV- Any time .org ) . 

'TV-Anytime Phase 1' (TVA-1) is the first full and synchronized set of specifications established by the TV-Anytime 
Forum. TVA-1 features enable the search, selection, acquisition and rightful use of content on local and/or remote 
personal storage systems from both broadcast and online services. 

The features are supported and enabled by the specifications for Metadata, Content Referencing, and Bi-directional 
Metadata DeHvery Protection, TS 102 822-3 sub-parts 1 [12] and 2 [13], TS 102 822-4 [14], TS 102 822-6-2 [15] and 
TS 102 822-7 [16]] respectively. All Phase 1 Features listed in TV035r6 are enabled by the normative TV-Anytime tools 
specifications. This list of Phase 1 Features is to be used as guidance to manufacturers, service providers and content 
providers regarding the implementation of the Phase 1 TV-Anytime specifications. 
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Scope 



The present document is the sixth in a series of "S-series" specification documents produced by the TV-Anytime Forum. 
These documents establish the fundamental specifications for the services, systems and devices that will conform to the 
TV-Anytime standard, to a level of detail that is implementable for compliant products and services. 

As is common practice in such standardization efforts, these specification documents were preceded by requirements 
documents, which define the requirements for the TV-Anytime services, systems, and devices. 

Congruent with the structure defined in the initial TV-Anytime Call for Contributions (TV014r3), these specifications 
are parsed into three major areas: Metadata, Content Referencing, and Rights Management and Protection. Within these 
general areas, four specifications have been developed to date: TS 102 822-3-1 [12], TS 102 822-3-2 [13], 
TS 102 822-4 [14], TS 102 822-6-1 (the present document), TS 102 822-6-2 [15] and TS 102 822-7 [16]. A 
specification for TS 102 822-5 is still under development. See the several TV-Anytime Calls for Contributions for more 
detail on the derivation and background of these categories and their respective roles in the TV-Anytime standardization 
process. 

The first two documents in the TV-Anytime S-series are intended to define the context and system architecture in which 
the standards in TS 102 822-3-1 [12], TS 102 822-3-2 [13], TS 102 822-4 [14], TS 102 822-6-1 (the present document), 
TS 102 822-6-2 [15] and TS 102 822-7 [16] are to be implemented in "Phase 1" of the TV-Anytime environment. The 
first document in the series (TS 102 822-1 [25]) provides benchmark business models against which the TV-Anytime 
system architecture is evaluated to ensure that the specification enable key business applications. The next document in 
the series (TS 102 822-2 [11]) presents the TV-Anytime System Architecture. These two documents are placed ahead of 
the other three for their obvious introductory value. (Note that TS 102 822-1 [25] and TS 102 822-2 [11] are largely 
informative documents, while the remainder of the S-series is normative. Also note that a "Phase 2" of the TV-Anytime 
process is currently underway, in which additional requirements and specifications that will build on Phase 1 are being 
developed. Readers are encouraged to check the TV-Anytime Forum's website at www. TV -Any time. ox^ for the most 
recent status of its specifications.) 

Although each of the S-series documents is intended to stand alone, a complete and coherent sense of the TV-Anytime 
system standard can be gathered by reading all of the Phase 1 specification documents in numerical order. 

The scope of the present document, comprises the delivery of TV-Anytime metadata and content referencing information 
via a bi-directional network using a PDR's return path. 

The requirements for this technology are outlined in the TV-Anytime Forum's Requirement Series R-1 document [10]. 
The following paragraphs from those requirements give an overview of the return path's use: 

"The consumer can get more information about the programme from either the content provider or from a 
programme information service offered by a third party. This could include programme specifications (such as 
source, duration, format, storage location, etc.), programme schedules, commentary, critiques, liner notes from 
the provider or third parties, etc." 

"A Return Path is a data connection from a consumer's home digital storage system (e.g. PDR) to one or more 
service providers. The return path gives the consumer access to interactive content, such as the Internet and 
interactive television. It also allows service providers to access consumer profile/preference information in 
order to make business decisions regarding content that is provided to the consumer." 

The present document describes a client-initiated means for requesting metadata from, and submitting user-centric data 
to, IP based web services. In the present document, these web services are termed "metadata services". The 
specification also defines a means for describing and discovering such metadata services, but does not address the 
unidirectional delivery of metadata over IP networks, or the delivery of content over IP networks. A more complete 
definition of the scope of this work, along with the system requirements, may be found in document TV 150, 
"Requirements and Scenarios for the Bi-directional Transport of Metadata" [3]. 
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Definitions, abbreviations and conformance 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

acquisition: retrieval of content 

application: a specific set of functions running on the PDR. Some applications use metadata, either automatically or 
under consumer control 

autliority: organization that creates CRIDs 

bi-directional network: a network that supports two way, point-to-point, one-to-many, and many-to-many data 
delivery 

NOTE: The Internet is an example of such a network. A PDR may access a bi-directional network using its return 
path. 
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capture: storing the acquired content (e.g. to local storage) 

content: anything the viewer would like to access (movies, games, TV programmes, radio programmes, etc.) 

content creator: producers of the content 

content provider: entity that acts as the agent for and is the prime exploiter of the content 

content reference: pointer to a specific content item 

location resolution: process of establishing the address (location and time) of a specific content instance from its GRID 
locator: time and place where a content item can be acquired 

metadata: generally, data about content, such as the title, genre, and summary of a television programme 
NOTE: In the context of TV-Anytime, metadata also includes consumer profile and history data. 

metadata service: service that provides TV-Anytime data using a server on a bi-directional network 

NOTE: The formats of the data and the protocols used to deliver that data are defined by the present document. 

programme: editorially coherent piece of content 

NOTE: Typically, a programme is acquired by the PDR as a whole. 

resolving authority: body which provides location resolution 

Resolving Authority Record (RAR): information needed for retrieving the location resolution data for the given 
authority 

return path: part of the bi-directional distribution system from the consumer to service provider 

segment: continuous portion of a piece of content, for example a single news topic in a news programme 

service provider: aggregator and supplier of content which may include gateway and management roles 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ARIB Association of Radio Industries and Businesses 

NOTE: A Japanese standards organization. 

ATSC Advanced Television Systems Committee 

NOTE: American based standards organization for establishing technical standards for advanced television 
systems, including digital high definition television. 

BiM Binary format for multimedia description streams 

NOTE: Defined in ISO/IEC 15938-1 [26] (MPEG-7 Systems part). 

CE Consumer Electronics 

CRID Content Reference Identifier: identifier for content that is independent of its location 

DNS Domain Naming System: system used on the Internet to register names that can then be mapped 

into IP addresses using a DNS server 
DVB Digital Video Broadcasting 

NOTE: Set of standards used for European digital TV broadcasting. 

EPG Electronic Programme Guide 

NOTE: Means of presenting content to the consumer, allowing selection of desired content. 

HTTP HyperText Transfer Protocol 

IP Internet Protocol 

NOTE: Generic name for the network protocols used on the Internet. 
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IPR 

PDR 

RAR 

SI 



Intellectual Property Rights 
Personal Digital Recorder 
Resolving Authority Record 
System Information 



NOTE: Collection of information tables used in DVB. 

SOAP Simple Object Access Protocol 

SQL Structured Query Language 

TCP Transmission Control Protocol 

UDDI Universal Description Discovery & Integration 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

VOD Video On Demand 

W3C World Wide Web Consortium 

WSDL Web Services Description Language 

WS-Inspection Web Services Inspection Language 

XML Extensible Markup Language 

3.3 Conformance 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 21 19 [6]. 

It is important to note that OPTIONAL and RECOMMENDED elements of the specification, if they are implemented, 
MUST be implemented in the manner documented in the present document. 



4 Introduction 

The TV-Anytime Forum has defined a number of data types that can be exchanged between TV-Anytime devices. These 
include programme metadata, content referencing information, and user-centric metadata. The present document is 
concerned with data exchange between TV-Anytime clients and metadata servers over a bi-directional network using the 
return path. A TV-Anytime client is typically a PDR, although in this document the client can be any Internet connected 
device. These devices do not necessarily need to have the ability to display or store content, since many types of devices 
can exploit TV-Anytime metadata services (e.g. a mobile phone displaying an EPG). 

Programme metadata and content referencing information can be delivered unidirectionally (e.g. via traditional 
broadcast or IP multicast) or via a bi-directional network. The reasons a TV-Anytime provider might choose to deliver 
data via a bi-directional network are as follows: 

• It allows a richer set of metadata to be delivered, since there are much lower bandwidth constraints. 

• It allows TV-Anytime data providers without access to a broadcast system to deliver metadata to clients. 

• It allows TV-Anytime data providers to personalize the metadata they offer according to the source of the 
request. 

• It allows a range of client devices, which are not necessarily able to receive broadcast data, to access and 
exploit TV-Anytime data. For example, a mobile phone or personal organizer could use the metadata service to 
show the user an EPG. 

User-centric metadata can only be delivered from a PDR to a TV-Anytime metadata service when a return path is 
available and the user authorizes it. The submission of such user data allows the metadata service to provide a variety of 
value adding services, which are more completely described in clause 6.5 of the TS 102 822-3-1 [12]. 

The present document defines the protocols that allow these transactions to take place in an interoperable fashion. Note 
that, due to the widespread nature and mass penetration of the Internet, the TV-Anytime Forum has completely specified 
the transport and network layer protocols (TCP/IP) necessary for end-to-end interoperability. This is in contrast to 
unidirectional transport mechanisms, which are not completely specified by the TV-Anytime Forum, but instead defined 
individually by the bodies responsible for the various broadcast standards used around the world (e.g. ARIB, ATSC, 
DVB, etc.). 
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To use a TV-Anytime metadata service a client takes the steps illustrated in figure 1 . 




Discover 

Metadata 

Service 



Obtain 
Capability 
Description 



Exploit 

Metadata 

Service 




URL 



Metadata Service 
Capability Description 



Figure 1 : The steps in using a TV-Anytime metadata service 

These steps are described in more detail in the following three clauses (in reverse order). Note that a metadata service 
MUST provide a description capability (see clause 7), but the support for metadata service discovery 
(see TS 102 822-6-2 [15]) is OPTIONAL. The middle step typically will only occur when a metadata service is first 
discovered or updated, and not each time the metadata service is used. 

4.1 Types and Functionalities of IVIetadata Services 

TV-Anytime metadata services can be broken into two basic types, which are shown in figures 2 and 3. The metadata 
services specified are all request-response based. This can be seen in the two figures - the network transaction is always 
point-to-point (client to server), and the transaction is always initiated by the client. 



4.1.1 



IVIetadata Retrieval 



Metadata retrieval occurs when a client wishes to obtain certain metadata from a metadata service that it has previously 
discovered and obtained a capability description for. The following list gives some examples of metadata retrieval. 

• A client wishes to obtain programme reviews for a CRID. The client sends a request specifying the CRID and 
type of metadata required, and the metadata service responds with the appropriate ProgramReviewTable. 

• A client wishes to obtain the schedule information for a particular channel over the next week. The client 
sends a request specifying the channel, date range, and type of metadata required. The metadata service returns 
a ProgramLocationTable and Programinf ormationTable corresponding to the programmes on 
that channel. 

• A client wishes to search a metadata service that specializes in movie information. The client sends a request 
specifying the type of movie (e.g. the genre is "Western", and the star is "John Wayne"), and the type of 
metadata required. The metadata service returns a number of matching movies, using a 

Programinf ormationTable and ProgramReviewTable. 
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Metadata 
Service 



IP Network 



Request 




Metadata 



NOTE 1 : Any party capable of delivering compliant TV-Anytime data could provide a metadata service. Examples 

include: content creators, content providers, service providers, consumer electronics manufacturers and 

third parties aggregation services. 
NOTE 2: The request contains parameters that specify the type of metadata required by the client. 
NOTE 3: The types of metadata returned could be any of the non user-centric data specified in the 

TS 102 822-3-1 [12] (i.e. the fragments defined in clause 4.3.1.1 of TS 102 322-3-2 [13]), along with 

content referencing information. 

Figure 2: Client requesting metadata from a metadata service 
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4.1 .2 Submission of User-centric Metadata 

Submission of user-centric metadata offers a number of possible benefits to both consumers and metadata service 
providers. These are described in clause 6.5 of the TS 102 822-3-1 [12]. Ensuring the privacy of these transactions and 
that the metadata service provider is trustworthy is essential to the submission of user-centric metadata. The means by 
which this is ensured is not defined by the present document. 



IP Network 



User-centric data 




Acknowledgement 



NOTE 1 : In this case, the metadata service is a user data aggregator. Any of the parties listed for figure 2, or any 
other party capable of usefully exploiting TV-Anytime usage information in a trustworthy fashion, could 
provide the metadata service. 

NOTE 2: In principle, the user-centric data may be any of the types defined in the Metadata Specification 

(TS 102 822-3-1 [12] (e.g. userPreferences and UsageHistory). For the purposes of this version of 
the specification, only a submission of carefully constrained, anonymous UsageHistory instances is 
allowed. 

Figure 3: Client submitting user-centric data to a service provider 

4.2 Metadata Service Capability Descriptions 

In order to exploit usefully the metadata services described in the previous clause, the client needs information about the 
nature of the metadata service being offered. This is because different metadata services will provide different types of 
metadata and can be queried in different ways. For example, some metadata services may offer just content referencing 
information, whilst others may provide programme metadata but no segmentation information. Similarly, whereas one 
server may only be able to accept simple requests for metadata based on a CRID, another server may offer much more 
sophisticated querying and sorting capabilities. Moreover, different types of queries are only useful if a client is able to 
establish sensible values with which to query. An example of this is a query for scheduling data 
(ProgramLocationTable). In order to query for scheduling information on a particular content delivery service, 
the client needs to know the content delivery services for which that metadata service has data. 

To address this issue, each metadata service provides, on request from a client, a capability description. This capability 
description allows a client to flexibly query a metadata service, without making requests that will not be supported by 
that metadata service. Furthermore, it allows metadata service providers to flexibly implement the server in a way that 
is appropriate to the data that they have available. 



4.3 Metadata Service Discovery 



Metadata service discovery is the process by which a cUent establishes a URL where a TV-Anytime metadata service 
can be found. There are a number of ways this process can occur, but only the third method (see clause 4.3.3) is 
addressed by the present document. 
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4.3.1 Non-Standardized Discovery 

A number of methods exist for discovering the URLs of metadata services that will not be standardized by the 
TV-Anytime Forum. The following list gives some examples. 

• The client might be pre-programmed with a set of URLs that refer to one or more metadata services. This will 
typically be useful in a vertical market, or tightly controlled horizontal market. 

• A user might manually enter a URL of a new metadata service he is interested in, using some means of text 
input. 

• The software on a client may be updated using software updates delivered via a unidirectional broadcast, or 
over the return channel. 

4.3.2 Unidirectional Delivery of Discovery Information 

TS 102 822-2 [11] and TS 102 822-4 [14] define ways, or requirements on the underlying transport, in which the URL 
of a bi-directional metadata and/or content referencing service can be discovered from TV-Anytime information inserted 
in a unidirectional stream. The present document defines how a client can usefully exploit the discovered service using 
the resulting URL. 

4.3.3 Client-Initiated Discovery Using the Bi-directional Network 

This mode of metadata service discovery involves using the bi-directional network to access a "Yellow Pages" of 
TV-Anytime metadata services. The mechanism is based upon W3C standards for web service discovery (UDDI [19] 
and WS -Inspection [21], the use of which is standardized by the TV-Anytime Forum, according to the rules given in 
clause 5 in TS 102 822-6-2 [15]. Support for these discovery techniques by clients and servers is OPTIONAL. 



Metadata Service Types 



The TV-Anytime Forum defines two types of metadata web service. Each type of web service can be thought of as a 
remote procedure with a well-defined set of inputs and outputs and a well-defined behaviour. In WSDL [20] 
terminology, this remote procedure is known as an operation (see annex A). The metadata retrieval operation 
(see clause 4.1.1 is called the get_Data operation, and the user description submission operation (see clause 4.1.2) is 
called the submit_Data operation. 

The types used in the requests and responses to TV-Anytime metadata services are defined in the target namespace: 
"urn:tva:transport:2002" . This allows Schema aware tools to validate the various messages. The types defined in 
TS 102 822-3-1 [12] and TS 102 822-4 [14] schemas are referenced in the transport namespace (using XML Schema's 
import mechanism). 

The Schema fragments in the following clauses are all defined within this namespace. The corresponding namespace 
qualifier used in these Schema fragments is "tns:" The complete XML Schema file 
(tva_transport_types_vl O.xsd) may be found attached to the present document as part of a common Zip file. 



5.1 get_Data Operation 



The get_Data operation allows a client to query a server in order to retrieve TV-Anytime data for a set of 
programmes or programme groups. The following list gives a few examples of the types of functionality that a 
TV-Anytime metadata provider can offer using a get_Data operation. 

• Operation that takes a list of CRIDs and returns content referencing data for those CRIDs. 

• Operation that takes a list of CRIDs and returns TV-Anytime metadata for those CRIDs. 

• Operation that accepts a query for programmes with particular metadata attributes (e.g. with a particular genre, 
or starring a certain actor, etc.) and returns matching programmes. 
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• Operation that accepts a query for programmes broadcast at a certain time or on a certain channel and returns 
matching programmes. 

A get_Data operation can, in principle, support all these types of queries, as well as more complex queries, 
involving a wide range of metadata constraints, and logical combinations of those constraints. 



5.1.1 Request Format 



The request format allows the client to specify three types of parameters. The semantics and structure of these three 
parameters are explained in more detail in the subsequent clauses. 

<element name="get_Data" type="tns : get_Data"/> 
<complexType name="get_Data"> 
<sequence> 

<element name="QueryConstraints "> 
<complexTYpe> 
<choice> 

<element name="PredicateBag" type="tns :PredicateBagType"/> 
<element name="BinaryPredicate" type="tns :BinaryPredicateType"/> 
<element name="UnaryPredicate" type="tns : UnaryP r edi cat e Type" /> 
</choice> 
</complexType> 
</element> 

<element name="RequestedTables" type="tns :RequestedTablesType"/> 
</sequence> 

Ottribute name="maxPrograms" type="unsignedlnt "/> 
</complexType> 



Name Definition 

QueryConstraints A REQUIRED parameter that defines, by means of one or more 

logical predicates the set of "result records" that the client is 
interested in. See clause 5.1.1.4 for a definition of "result record". For 
example, this set could be specified using a list of CRIDs, the 
programmes that have the keyword "Thriller" in their metadata, or the 
programmes that correspond to a BroadcastEvent on Channel 2 on 

Saturday, etc. 

RequestedTabies A REQUIRED parameter that specifies the view of the metadata 

required by the client. This parameter determines the types of 
metadata that are returned for each result, and also allows the client 

to specify simple sort criteria to be applied to the result. 

maxPrograms An QPTIQNAL upper limit on the number of programmes that will be 

returned. This is to prevent the client being overloaded by very large 
result sets. If this attribute is not there the server should return all the 
matching results. 



5.1.1.1 Query constraint parameters 

This parameter consists of a set of logical predicates, which can be nested together (according to the rules of first order 
predicate logic) and together define the set of results that a client is interested in. (Using SQL terminology, this 
parameter plays a similar role to the WHERE clause in an SQL SELECT statement.) Unlike SQL, the interpretation of 
the logical constraints does not have to be strict - the results returned do not need to precisely match the criteria 
specified in the query. This provides opportunity for metadata service providers to offer value adding search algorithms. 

<complexType name="PredicateBagType"> 
< sequence maxOccurs=" unbounded" > 
<choice> 

<element name="PredicateBag" type="tns :PredicateBagType"/> 
<element name="BinaryPredicate" type="tns :BinaryPredicateType"/> 
<element name="UnaryPredicate" type="tns : Una r yP r edi cat e Type" /> 
</choice> 
</sequence> 

<at tribute name=" con text Node" type="tns : context Node ID Type" /> 
ottribute name="negate" type="boolean" def ault="f alse" /> 
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<attribute name="tYpe" tYpe="tns :PredicateBagTypeType"/> 
</complexType> 

< simple Type name="PredicateBagTypeType"> 
<restriction base="string"> 
<enumeration value="AND" /> 
<enumeration value="OR"/> 
</restriction> 
</simpleType> 
<complexType name="BinaryPredicateType"> 

<attribute name="f ieldID" type="tns : f ieldlDType" use="required"/> 
<attribute name="f ieldValue" type="string" use="required"/> 
<attribute name="test" default="equals" 
type="tns : Binar yP redi cat eTest Type" /> 
</complexType> 
<complexTYpe name= " Unar yP redi cat e Type "> 

<attribute name="f ieldID" type="tns : f ieldlDType" use="required"/> 
<attribute name="test " def ault="exists" 
type="tns : Una ryP redi cat eTest Type" /> 
</complexType> 

< simple Type name="BinaryPredicat eTest Type "> 
<restriction base="string"> 
<enumeration value="equals" /> 
<enumeration value="not_equals" /> 
<enumeration value=" contains" /> 
< enumeration value="greater_than" /> 
<enumeration value="greater_than_or_equals" /> 
<enumeration value="less_than" /> 
<enumeration value="less_than_or_equals " /> 
</restriction> 
</simpleTYpe> 

< simple Type name="UnaryP redi cat eTest Type "> 
<restriction base="string"> 

<enumeration value="exists" /> 
</restriction> 
</simpleType> 
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Name 



Definition 



PredicateBagType A PredicateBagType contains one or more BinaryPredicate, 

unaryPredicate or PredicateBag children, andls used to express 

logical relationships between tliese ciiildren. 

type This attribute expresses the logical relationship between the children of 

this PredicateBag. It can take the values "AND" or "OR". The attribute 
is REQUIRED when there are two or more children. The attribute is 

meaningless if the PredicateBag contains a single element. 



negate 



This attribute reverses the Boolean evaluation (true/false) of the 
PredicateBag. If there are two or more children predicates, it is 
evaluated after the children predicates have been combined; i.e. the 
type attribute has tighter precedence. 



contextNode If present, this attribute restricts the way in which fragments are matched 

with this PredicateBag. Specifically, the predicates contained within 
this PredicateBag IVIUST all be satisfied by the fields in a single XML 
element within the fragment. The root node of this XML element is 
defined by the contextNodeiD value of the contextNode attribute. 
The contextNodeiD values used here MAY have a definition that 
uses a multiple XPath expression (i.e. the contextNodeiD may refer to 
multiple nodes, but the actual node is given by the RequestedTable 
element). When used, all the contextNodeiD values referenced in the 
predicates that are descendants of this PredicateBag MUST refer to 
fields that are descendants of the contextNode element in the XML 

Schema. 

unaryPredicateType/Bin A Boolean test that Can be evaluated on a field stored by a metadata 

aryPredicateType service. See clause 5.1 .1 .1 .1 for a definition of field. 

f ieldiD A REQUIRED f ieldiD value (see clause 5.1 .1 .1 .1 ) that defines the 
field being tested (e.g. GRID, Title, etc.). 



test 



The relationship between the f ieidiD and the f ieidvaiue. 
attribute can take the value "equals", "not_equals", "contains", 
"greater_than", "greater_than_or_equar', "less_than", 
"less_than_or_equals", or "exists". 



This 



f ieldValue 



The value being tested. This attribute is not present in predicates of the 
type UnaryPredicateType. 



Annex C provides some examples that illustrate the types of queries a client can issue. 

5.1.1.1.1 Identifying contextNodes 

A contextNode is an XML node of the following type: element. 

• Element contextNode can correspond to nodes with an XML Schema complexType model (an element 
containing other elements or attributes). 

ContextNodes are defined using an XPath expression based on a subset of XPath (for a definition of this XPath subset, 
see TS 102 822-3-1 [12]). Instead of using this verbose XPath expression directly in every predicate, all fields used in a 
query MUST be assigned a contextNode. A contextNode is just a syntactic shortcut that provides a consistent 
alias for the full XPath expression that identifies a node. The TV-Anytime Forum defines a normative subset of nodes 
with predefined contextNode values. 

In order to define a list of contextNode definitions the following piece of XML Schema is used. 

<element name="ContextNodeIDDef initionList " 

type="tns : ContextNodelDDef initionListType"> 
<key name="UniqueContextNode"> 

<selector xpath="tns : ContextNodelDDef init ion" /> 
<field xpath=" @ contextNode ID" /> 
</key> 
</element> 
< complexType name="ContextNodeIDDef initionList Type" > 
<sequence> 

<element name=" ContextNodelDDef init ion" maxOccurs=" unbounded" > 
<complexType> 

<attribute name="contextNode" type="NCName"/> 
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< at tribute name="contextNodeDef inition" 
type="tns : contextNodeDef initionListType" /> 
</complexType> 
</element> 
</sequence> 

<attribute name="targetNamespace" type="anyURI" use="required"/> 
</complexType> 

< simple Type name="contextNodeDef initionType"> 
<restriction base="token"> 

<pattern value=" (/ ( (\i\c*:) ? (\i\c*) ) ) * ( (/text\ (\) ) I (/@ ( (\i\c*:) ? (\i\c*) ) ) ) ?"/> 
</restriction> 
</simpleType> 
< simple Type name="contextNodeDef initionListType"> 

<list itemType="tns : contextNodeDef initionXype" /> 
</simpleType> 

< simple Type name="contextNodeIDType"> 
<restriction base="QName" /> 
</simpleType> 



Name 



Definition 



Cont extNode I DDef initionListType 



Provides a uniform structure for defining a map of 
contextNode values to XPatii expressions. 



tar get Name space 



The field definition namespace to which this 
contextNode map belongs. The namespace can be 
used to unambiguously reference contextNode values 
from multiple namespaces. The use of namespaces here 
is similar to, but distinct from, the use of namespaces to 
identify XML Schema, and is in accordance with 
Namespaces in XIVIL [2]. 



Cont extNode IDDef inition 



Contains a single contextNode map. 



Cont extNode Id 



A name used to identify this field. All the contextNode 
values defined in a particular namespace MUST be 
unique. 



Cont extNodeDe script ion 



A list of XPath expressions that defines the fields that MAY 
be searched when this contextNode is used. Each item 
in the list is a regular expression that corresponds to the 
XPath subset defined in TS 102 822-3-1 [12], 
clause 4.8.5.1 .2. The XPath namespace context consists 
of the namespace declarations that are in scope in the 
XML instance document at the point that this attribute 
appears. 



cont extNode ID Type 



The simple type that all contextNode values are based 
on. Note that the use of QName ensures that 
contextNode values are always namespace qualified. 



Element instances based upon the ContextNodelDDef InitionListType are used to specify the TV-Anytime 
Forum's predefined subset of contextNode values. 

The predefined subset of contextNode allocations, which belong in the urn:tva:transport:contextNodeIDs:2002 
field definition namespace, can be found in annex B. Within the present document the prefix "tvac" is used to denote 
this namespace. 

Within this same namespace, some contextNode identifiers contain multiple XPath statements. A server HAS to use the 
specific Xpath statement relevant to the considered RequestedTable when performing a query based on these 
contextNodes as it does for the CRID field. Table 2 defines some additional special case contextNode identifiers, along 
with a semantic description of their meaning. These special case contextNodes are those that cannot be identified using 
single XPath expressions. 
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Table 1 : Description of special case contextNodeiD values (informative) 
ContextNodelD Comment 



Creditsltem 



The Creditsltem element of the CreditsList element within the 
Programlnformation or Grouplnformation table. 



Audi oAt tributes 



The AudioAttributes element of the AVAtrributes element within 
the Programlnformation or ProgramLocation tables. 



VideoAt tributes 



The VideoAttributes element of the AVAtrributes element within 
the Programlnformation or ProgramLocation tables. 



Awards List It em 



The AwardsListltem element of the AwardsList element within the 
Programlnformation or Grouplnformation tables. 



Programlnformation The Programlnformation element of the Programlnformation table. 

Grouplnformation The Grouplnformation element of the Grouplnformation table. 

BroadcastEvent The BroadcastEvent element of the ProgramLocation table. 

Schedule The Schedule element of the ProgramLocation table. 

OnPemandProgram The OnPemandProgram element of the ProgramLocation table. 

Service In format ion The Servicelnformation element of the Servicelnformation table. 

PersonName The PersonName element of the Creditslnformation table. 

OrganizationName The OrganizationName element of the Creditslnformation table. 

The Segmentlnformation element of the Segmentlnformation 

table. 



Segmentlnformation 



Segment Group Information 



The SegmentGrouplnformation element of the 
Segmentlnformation table. 



Review The Review element of the ProgramReview table. 



5.1.1.1.2 Identifying fields 

A field is an XML node of the following type: attribute, text or element. 

• Attribute fields and text fields (the contents of an element's text node) have no structure, so can be represented 
as a string whose value can be tested against the f ieldValue given in a predicate. 

• Element fields can correspond to nodes with an XML Schema complexType model (an element containing 
other elements or attributes). Fields of this type can only be used in a predicate if the test is "exists". An 
example of why this might be useful is given in annex C, example 8. Sorts cannot be based upon an element 
field. 

Fields are defined using an XPath expression based on a subset of XPath (for a definition of this XPath subset, see 
TS 102 822-3-1 [12]). Instead of using this verbose XPath expression directly in every predicate, all fields used in a 
query MUST be assigned a f ieldlD. A f ieldID is just a syntactic shortcut that provides a consistent alias for the 
full XPath expression that identifies a field. The TV-Anytime Forum defines a normative subset of fields with predefined 
fieldID values. 

In order to define a list of f ieldID definitions the following piece of XML Schema is used. 

<element name="FieldIDDef initionList " 

tYpe="tns :FieldIDDef initionListType"> 
<key name="UniqueField"> 

<selector xpath="tns :FieldIDDefinition"/> 
<field xpath="@fieldID"/> 
</keY> 
</element> 

< complexType name="FieldIDDef initionListType"> 
<sequence> 

<element name="FieldIDDef inition" maxOccurs="unbounded"> 
<complexType> 

<attribute name="f ieldID" type="NCName"/> 
< at tribute name="fieldDef inition" 

type="tns : f ieldDef initionListType"/> 
</ complexType > 
</element> 
</sequence> 

<attribute name="targetNamespace" type="anyURI" use="required"/> 
</ complexType > 
< simple Type name=" f ieldDef initionType"> 
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<restriction base="token"> 

<pattern value=" (/ ( (\i\c*:) ? (\i\c*) ) ) * ( (/text\ (\) ) I (/@ ( (\i\c*:) ? (\i\c*) ) ) ) ?"/> 

</restriction> 
</simpleType> 
< simple Type name=" f ieldDef initionListType"> 

<list itemType="tns : f ieldDef initionType"/> 
</simpleType> 
< simple Type name=" f ieldIDType"> 

<restriction base="QName" /> 
</simpleType> 
< simple Type name=" f ieldIDListType"> 

<list itemType="tns : f ieldIDType"/> 
</simpleType> 



Name Definition 



FieldiDDef initionListType Provides a uniform structure for defining a map of f ieldiD 

values to XPath expressions. 

targetNamespace The field definition namespace to which this f leidiD map 

belongs. The namespace can be used to unambiguously 
reference f ieidiD values from multiple namespaces. The 
use of namespaces here is similar to, but distinct from, the 
use of namespaces to identify XIVIL Schema, and is In 

accordance with "Namespaces in XML" [2]. 

FieldiDDef inition Contains a single fieidiD map. 

fieidiD A name used to identify this field. All the fieidiD values 

defined in a particular namespace MUST be unique. 

f ieldDef inition A list of XPath expressions that defines the fields that MAY be 

searched when this f leidiD is used. Each item in the list is 
a regular expression that corresponds to the XPath subset 
defined in TS 102 822-3-1 [12], clause 4.8.5.1.2. The XPath 
namespace context consists of the namespace declarations 
that are in scope in the XML instance document at the point 

that this attribute appears. 

fieidiDType The simple type that all fieidiD values are based on. Note 

that the use of QName ensures that f ieidiD values are 

always namespace qualified. 

fieidiDListType A whitespace-separated list of f ieidiD values 

Element instances based upon the FieldiDDef initionListType are used in two places in the present 
document. Firstly, it is used to specify the TV-Anytime Forum's predefined subset of f ieldID values. Secondly, it 
MAY appear in a get_Data operation's capability description, where it is used to allocate f ieldID values to fields 
not in the normative subset. See clause 7.1.3 for an explanation of how this is done. In this, way servers can extend their 
metadata services to flexibly support querying or sorting on any field in the TV-Anytime metadata and content 
referencing Schema. 

The predefined subset of f ieldID allocations, which belong in the urn:tva:transport:fieldIDs:2002 field definition 
namespace, can be found in annex B. Within the present document the prefix "tvaf" is used to denote this namespace. 

Within this same namespace, some field identifiers contain multiple XPath statements. A server MAY use any of these 
XPath statements when performing a query based on these fields. Table 2 defines some additional special case field 
identifiers, along with a semantic description of their meaning. These special case fields are those that cannot be 
identified using single XPath expressions. 

Table 2: Description of special case f ieldiD values (informative) 

FieidiD Comment 

The GRID when it is used in the context of identifying the GRID 
GRID with which a fragment is associated. 
Details of this f ieidiD can be found in table 3. 

The start attribute of the DecomposedLocator element from 
start the LocationResult element within the content referencing 

table. 
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FieldID 



Comment 



Title 



Any title element (Title or shortTitle) from the 
Programinf ormation, Groupin format ion, 
ProgramLocation or Segmentinf ormation tables. 



TitleLanguage 



The language attribute of the Title element from the relevant 

Programinf ormation, Groupin format ion, 
ProgramLocation or Segmentinf ormation table. 



Synopsis 



Any Synopsis element from the Programinf ormation, 
Groupinf ormation, ProgramLocation or 
Segmentinf ormation tables. 



Synopsis Language 



The language attribute of the Synopsis element from the 

Programinf ormation, Groupinf ormation, 
ProgramLocation or Segmentinf ormation tables. 



Publi sheds tart 



The PubiishedTime element of any items of type 
ScheduleEventType, and the StartOf Availability 
element of a OnOemandProgram item. If the 
StartOf Availability element is not present, it is assumed to 
be the current time (i.e. available now). 



PublishedDuration 



The PublishedDuration element of any items of type 

ScheduleEventType . 



Fragment ID 



Any fragment Id attribute. See Annex C for an example of how 
this f ieidiD may be used to retrieve a specific fragment. 



fragment Vers ion 



Any f ragmentversion attribute. See Annex C for an example 
of how this f ieidiD may be used to update a specific fragment. 



AudioCoding 



The coding element from the AudioAttributes element from 

the Programinf ormation or ProgramLocation tables. 



AudioChannels 



The NumOf Channels element from the AudioAttributes 
element within the Programlnformation or ProgramLocation 
tables. 



VideoAspectRatio 



The AspectRatio element from the VideoAttributes element within 
the Programlnformation or ProgramLocation tables. 



Keyword 



The Keyword element within the Programlnformation or 
Grouplnformation tables. 



KeywordLanguage 



The language attribute from the Keyword element within the 
Programlnformation or Grouplnformation tables. 



Genre 



The Genre element within the Programlnformation or 
Grouplnformation tables. 



Language 



The Language element from the Programlnformation or 
Grouplnformation tables. 



Parental Guidance 



The ParentalGuidance element from the Programlnformation or 
Grouplnformation tables. 



Role 



The Role element from the cast list item that relates to cast 

member associated with the Programlnformation or 

Grouplnformation tables. 



FamilyName 



The FamilyName element from the cast list item that relates to 
cast member associated with the Programlnformation or 
Grouplnformation tables. 



GivenName 



The GivenName element from the cast list item that relates to cast 
member associated with the Programlnformation or 
Grouplnformation tables. 



AwardTitle 



The Title element from an awards list item within the 
Programlnformation or Grouplnformation tables. 



AwardYear 



The Year element from an awards list item within the 
Programlnformation or Grouplnformation tables. 



AwardNominee 



The Nominee element from an awards list item within the 
Programlnformation or Grouplnformation tables. 



AwardRecipient 



The Recipient element from an awards list item within the 
Programlnformation or Grouplnformation tables. 



RatingValue 



The RatingValue element from Review element within the 
Programlnformation or Grouplnformation tables. 



RatingScheme 



The RatingScheme element from Review element within the 
Programlnformation or Grouplnformation tables. 



ProductionDate 



The ProductionDate element from BasicDescription element within 
the Programlnformation or Grouplnformation tables. 
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FieldID 



Comment 



CreditName 



Any name element (FamilyName or GivenName) form the 
Programlnformation, Grouplnformation or ProgramReviews tables. 



ProgramURL 



The ProgramURL element from the BroadcastEvent Schedule, or 
OnPemandProgram element within the ProgramLocation table. 



FreeToView 



The Free element from the BroadcastEvent or Schedule element 
within the ProgramLocation table. 



EpisodeOf 



The EpisodeOf element from the Programlnformation element 
within the Programlnformation table. 



GroupType 



The value attribute of the GroupType element within the 
Grouplnformation table. 



ServiceURL 



The ServiceURL element of the Servicelnformation element within 
the Servicelnformation table. 



ServiceName 



The ServiceName element of the Servicelnformation element 
within the Servicelnformation table. 



Creditsltem 



The Creditsltem element of the CreditsList element within the 
Programlnformation or Grouplnformation table. 



Audi oAt tributes 



The AudioAttributes element of the AVAtrributes element within 
the Programlnformation or ProgramLocation tables. 



VideoAt tributes 



The VideoAttributes element of the AVAtrributes element within 
the Programlnformation or ProgramLocation tables. 



Awards List Item 



The AwardsListltem element of the AwardsList element within the 
Programlnformation or Grouplnformation tables. 



Programlnformation 



The Programlnformation element of the Programlnformation table. 



Grouplnformation 



The Grouplnformation element of the Grouplnformation table. 



BroadcastEvent 



The BroadcastEvent element of the ProgramLocation table. 



Schedule 



The Schedule element of the ProgramLocation table. 



OnDemandProgram 



The OnPemandProgram element of the ProgramLocation table. 



Servicelnformation 



The Servicelnformation element of the Servicelnformation table. 



PersonName 



The PersonName element of the Creditslnformation table. 



OrganizationName 



The OrganizationName element of the Creditslnformation table. 



Segment In format ion 



The Segmentlnformation element of the Segmentlnformation 
table. 



Segment Group Information 



The SegmentGrouplnformatlon element of the 
Segmentlnformation table. 



Review 



The Review element of the ProgramReview table. 



CSUri 



The uri attribute of the ClassificationScheme element within the 
ClassificationSchemeTable. 



CSAlias 



The mpeg7:alias attribute of the CSAlias element within the 
ClassificationSchemeTable. 



GenreCS 



The href attribute of the Genre element within the 
ProgramlnformationTable and GrouplnformationTable. 



If a metadata service wishes to support querying or sorting on a field within the normative subset it MUST use the 
predefined f ieldID . (I.e. servers MUST NOT define their own f ieldID for a field already in the normative 
subset.) 



5.1.1.1.3 



Primary index GRID fields 



Fragments containing CRIDs exist in many different locations in the TV-Anytime schema. Since CRIDs can occur in 
multiple places within a fragment (e.g. in a Grouplnformation fragment they can be used to refer to parent 
groups), the following table formally defines the CRID field that is used to identify the fragments in each case. 

The XPath expressions are namespace qualified. The present document assumes the expression content of the XPath 
e valuator has the following namespace prefixes: 



tva 
mpeg? 



urn:tva:ContentReferencing:2002 

urn:tva:metadata:2002 

urn:mpeg:mpeg7:schema:2001 



£75/ 



23 



ETSI TS 102 822-6-1 VI. 1.1 (2003-10) 



Table 3: The meaning of the GRID field in the different 7\^->*nyf//ne tables 



Table type 



XPath specification for GRID node set 
(ignore wtiitespace) 



Number 
matcties 



ContentRef erencing 



/cr: Content Re ferencingTable/cr: Re suit /@CRID 



Oor1 



Programin format ion 



/tva : TVAMain/tva : ProgramDescription/tva : Pro 
graminf ormationTable/tva : Programinf ormation 
/@programId 



Oorl 



Groupin format ion 



/tva : TVAMain/tva : ProgramDescription/tva : Gro 
uplnf ormationTable/tva : Groupin format ion/ @gr 
oupid 



Oorl 



ProgramReview 



ProgramLocation 



/tva : TVAMain/tva : ProgramDescription/tva : Pro 
gramReviewTable/tva : ProgramReviews/tva : Prog 
ram/@crid 



to many 



/tva : TVAMain/tva : ProgramDescription/tva : Pro 

gramLocationTable/tva : Schedule/tva : Schedule to many 

Event /tva : Program/@crid 

/tva : TVAMain/tva : ProgramDescription/tva : Pro 

gramLocationTable/tva : BroadcastEvent/tva : Pr to many 

ogram/@crid 

/tva : TVAMain/tva : ProgramDescription/tva : Pro 

gramLocationTable/tva : OnDemandProgram/tva : P to many 

rogram/@crid 

/tva : TVAMain/tva : ProgramDescription/tva : Pro 

gramLocationTable/tva : OnDemandService/tva : to many 

nOemandProgram/tva : Program/@crid 



Segment In formation 



/tva : TVAMain/tva : ProgramDescription/tva : Seg 
ment In f ormationTable/tva : Segment List /tva : Se 
gment Information /tva : ProgramRef /@crid 

The schema does not require this attribute. If it is omitted 
the implied GRID (from the parent segment group) IVIUST 
be used for the server to determine matching 
Segmentlnformation fragments based on the GRID field. 

/tva : TVAMain/tva : ProgramDescription/tva : Seg 
ment In f ormationTable/tva : SegmentGroupList /t 
va : Segment Group Information /tva : ProgramRef /@ 
crid 



to many 



to many 



5.1.1.1.4 Restrictions on the use of QueryConstraints 

The QueryConstraints element MUST NOT contain predicates with fields from the following tables: 

• ContentRef erencingTable. Content referencing information does not contain metadata attractors, so 
none of the fields are suitable as query constraints. 

• Creditsinf ormationTable. Credits information is considered to always be inlined from the point of 
view of specifying a search. In other words, fields based upon the credit information fields inside a 
BasicDescription element are used to constrain a search. 

There are two exceptions to these rules: 

• Searches using the fragment Id field and fragmentVers ion field can be used to retrieve or update a 
metadata fragment from any metadata table. 

• Searches based on the CRID field are a special case, which is considered in clause 5.1.1.1.3. 

Please note that a request with "QueryConstraints" containing disjunctive condition may lead sometimes to an 
ambiguous result (see example in clause C.9). 
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5.1 .1 .1 .5 Evaluating a predicate 



Although the f ieldID values specify precisely the field being matched, a metadata service is free to interpret which 
metadata fields are used to match the query f ieldValue. For example, if a query specifies a programme with a 
certain title, a server is free to match this string with any of the values given by the Title or ShortTitle 
elements. Similarly, if a query specifies a keyword search, a server could match the keyword on any of the stored 
keywords as well as words in the title and synopsis. In general, where the metadata schema offers alternative ways of 
representing the same information a metadata service SHOULD be lenient in matching either representation (e.g. a UK 
parental guidance of "18" might be considered to match an American rating of "X"). In particular, it is 
RECOMMENDED that a metadata service adopt the following behaviour. 

• If a controlled term is being matched, the server matches f ieldValue values specified using both the full 
URN for the controlled term, or a shortened alias form. 

• Any query field inside a BasicDescription element can give rise to a match for the corresponding field 
inside a Programinf ormation or Groupinf ormation fragment. E.g. a search for the field Title 
with value "Friends" could give rise to a programme GRID (episode of "Friends"), or a group GRID (series of 
"Friends"). If the client is only requested in one type of GRID, they can achieve this by requesting the 
appropriate table type in the RequestedTables parameter. 

• The fields within a BroadcastEvent can be considered to the match corresponding fields within a 
ScheduleEvent. This does not impact how the metadata service chooses to fragment the returned data 
(i.e. whether to use BroadcastEvent or Schedule fragments). 

The tests evaluated to determine the Boolean value of a predicate are self-explanatory, but the following should be 
noted. 

• equals. For numeric types, a server MUST consider values that are numerically equal to the query value to 
represent a match. For fields that have the anyURI type or some derived type (e.g. GRID, ServiceURL, etc.) 
equality MUST be based upon the rules defined for that particular URI. For fields that have the TVAIDType 
type (e.g. fragmentID, servicelD, etc.), equality MUST be based on the rules for matching ID and IDRef 
types, as defined in the XML specification [1]. 

• For other types derived from string, the server determines the notion of equality. It is REGOMMENDED that 
the server ignores leading and trailing white space and character case when comparing strings. The server may 
also employ fuzzy or other type of matching algorithms so that matches may still be returned if a name is 
misspelt in a query, say. 

• For fields that can contain multiple values (e.g. Title, Genre, Keywords, etc.), it is REGOMMENDED that the 
query f ieldValue is matched to any of the field values in a fragment. If the server has no data for a 
particular field, it is REGOMMENDED that the server considers the associated fragment not to match the 
predicate, as this can lead to very large result sets. However, if the query is sufficiently restrictive (no 
truncation of the response is necessary) it may be appropriate to relax this rule. 

• less_than, greater_than. The use of XPath and XML Schema mean that the metadata service is always aware 
of the Schema type of every field. If the type is duration, then the shortest time is considered to be the lesser. If 
the type is a date and/or time, then the earlier value is considered to be the lesser. If the type is numeric, then 
less_than has its obvious interpretation. 

• If the type is derived from a string, then the earliest string (according to a lexicographic sort) is considered to 
be the lesser. The comparison is based on the Unicode Technical Standard 10 GoUation Order [17] on elements 
normalized according to Unicode Normalization Form G [18]. By default, the collation takes place according 
to the Default Unicode Gollation Element Table in conjunction with Unicode Gollation Algorithm. A metadata 
provider may choose to use another collation table, in which case this is indicated by naming the collation 
table in the capability description (see clause 6.1). 

• For fields that can contain multiple values (e.g. Title, Genre, Keywords, etc.), the metadata service should base 
the comparison on the field it considers to be primary. For some elements, this is indicated using the type 
attribute with value "main". 

• If a fragment has no metadata for a particular field, the fragment SHOULD be tested as if the value for that 
field is the empty string. 
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exists. In order for this test to evaluate as "true", the metadata service MUST be able to populate the element or 
attribute with useful data. I.e. it is not sufficient to instantiate the element or attribute but leave it empty. 

contains. This test is only used to test fields that have a type derived from a string. For all other field types the 
test SHOULD not be used. 



5.1.1.2 



View on returned data 



This REQUIRED RequestedTables parameter defines the types of data that a metadata service will try to provide 
on each result it returns. To achieve this, the client includes a list of table types that it requires. For a given result set, a 
server SHOULD supply, if the appropriate metadata is available, the corresponding fragments for this result record 
from the requested tables. It is not an error if the appropriate metadata is not available (e.g. no segmentation information 
is available for that GRID), and the client MUST NOT assume that requested fragments will always be returned. 



<complexType name="Reque 
<sequence> 

<element name="Table 
<complexType> 
<sequence> 

<element name= 
minOc 
</sequence> 
<attribute name= 
<simpleTYpe> 
<restriction 
<enumerati 
<enumerati 
<enumerati 
<enumerati 
<enumerati 
<enumerati 
<enumerati 
<enumerati 
<enumerati 
</restrictio 
</simpleType> 
</attribute> 
</complexType> 
</element> 
</sequence> 
</complexType> 



stedTablesType"> 

" maxOccurs="unbounded"> 



SortCriteria" type="tns : SortCriteriaType' 
curs=" " maxOccurs="unbounded" /> 



'type' 

base= 
on va 
on va 
on va 
on va 
on va 
on va 
on va 
on va 
on va 
n> 



'required"> 



"st 

lue= 
lue= 
lue= 
lue= 
lue= 
lue= 
lue= 
lue= 
lue= 



ring > 

"ContentRe 

"Classific 

"Programln 

"Groupinf o 

"Creditsin 

"ProgramLo 

"Servicein 

"ProgramRe 

"Segment In 



f erencingTable" /> 
ationSchemeTable"/> 
format ionTable"/> 
rmationTable"/> 
format ionTable"/> 
cationTable"/> 
format ionTable" /> 
viewTable"/> 
format ionTable" /> 



Name 


Definition 


RequestedTables 


A list of table elements containing at least one entry. 


Table 


Specifies the type of table required by the client and the sort criteria 
to be applied to that table. 



Type Mandatory parameter giving the type of TV-Anytime table required by 

the client. Can take the values: ContentRef erencingTable, 
Classif icationSchemeTable, 

Programinf ormat ionTable, Groupinf ormat ionTable, 
ProgramLocat ionTable, Serviceinf ormat ionTable, 
ProgramReviewTable, Segmentinf ormationTable, and 
Creditsinf ormationTable . 



SortCriteria 



The sort criteria to be applied to that table. If not present the returned 
table will not necessarily be sorted. The order of the SortCriteria 
element is significant See clause 5.1 .1 .2.1 for a more complete 
explanation of sorting. 



£75/ 



26 ETSI TS 1 02 822-6-1 V1 .1 .1 (2003-1 0) 

A metadata service can choose whether or not to inline credits information directly, or to reference a fragment in the 
Creditsinf ormationTable. The request for a CreditsInformationTable determines if the server 
returns credits information at all, but does not impact the above choice on how to include the credits information. A 
server MUST NOT return credits information if the CreditsInformationTable is not listed in the 
RequestedTable parameter. The SortCriteria parameter SHALL be ignored if it is used in conjunction with 
the CreditsInformationTable. 

A Service Inf ormationTable will always be included in a response if a Service Information entry is 
being referenced (using a servicelDRef) from a ProgramLocationTable. Thus, an explicit request for a 
Serviceinf ormationTable will have no effect if a ProgramLocationTable is being returned. 
Nevertheless, if the client wishes to specify sort criteria for the Serviceinf ormationTable, it is useful to 
include it in the requested tables. 

5.1.1.2.1 Sort criteria 

<complexType name="SortCriteriaType"> 

Ottribute name="f ieldID" type="tns : f ieldlDType" use="required"/> 
<attribute name="order" type="tns : SortingOrderType" 
de fault=" ascending "/> 
</compIexType> 

< simple Type name=" Sort ingOrde r Type "> 
<restriction base="string"> 

<enumeration value=" ascending" /> 
<enumeration value=" descending" /> 
</restriction> 
</simpIeType> 



Name Definition 

Sorter it eriaType The definition of one sorting criteria to apply. 

fieidiD Specifies the field to use 

Order Defines the type of sorting to apply (either ascending or descending). 

Sorts are applied across the fragments contained in a given table. Sorts can be applied in either ascending order (with 
the least first) or descending order (with the largest first). The criteria by which fields are compared is identical to that 
used to make less_than (ascending search) and greater_than (descending search) comparisons, as specified in 
clause 5.1.1.1.5. One implication of this is that fragments included in the response containing no data for the field being 
sorted MUST be sorted as if that field had the value of the empty string. Another implication is that if the sort field can 
have multiple values in a single fragment (e.g. Title), the metadata service SHOULD be sorted on the primary value 
for that field. 

There can be a number of SortCriteria elements within the RequestedTables parameter. The metadata 
service uses this to apply a multi-tier sort, with the first sort applied using the first SortCriteria element in the 
list, the next sort using the second SortCriteria element (if any), and so on. If a server indicates that it supports 
one or more sort fields (see clause 7.1) for a table, then it MUST support a single-tier sort for that table. If a server 
indicates that it supports more than one sort field, then it MAY support a multi-tier sort for that table. The exact sort 
applied by the server is indicated in the response (see clause 5.1.2.1). If multi-tier sorting is supported, groups of 
fragments that are equivalent according to the criteria of one sort field are then sorted according to the criteria of the 
next sort field. For example, this allows a set of BroadcastEvent fragments to first be grouped into channels and 
then sorted according to time and date, and thus make the construction of an EPG on the client much more efficient. 
Such a sort could be specified as follows. 

<RequestedTables> 

<Table type="ProgramLocationTable"> 

<Sort Criteria f ieldID="tvaf : ServiceURL" order=" descending" /> 
<Sort Criteria f ieldID="tvaf : PublishedTime" /> 
</Table> 
</RequestedTabIes> 
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If the Sorter iter ia parameter contains a f ieldID value that refers to a field identifier containing multiple 
XPath expressions, the metadata service MAY choose any one of the XPath expressions for identifying which field to 
use for sorting that fragment. 

For example, if a result is a ProgramLocationTable containing both OnDemandProgram fragments and 
BroadcastEvent fragments, and the sort criteria is "PublishedStart", all the BroadcastEvent fragments will be 
sorted according to their published time (see table 2) followed by all the OnDemandProgram fragments sorted 
according to their first available time. 

The way in which a client establishes the fields for which sorting is supported (if any) is described in clause 7. 1 . 

5.1.1.3 Size limit parameter 

An OPTIONAL parameter (maxPrograms) can be inserted in the request. It is a positive integer and is used by the 
client to specify the number of records returned by a query. If a query results in a greater number of records, the server 
MUST return maxPrograms records, along with their corresponding metadata. 

Limiting the number of records being returned does not guarantee the client device's memory not being exceeded since 
there is no limit on the size of each of data associated with each record. Similarly, knowing the exact byte size of the 
response is not sufficient, since there is not a linear relationship between this figure and the size of the post-parsing in- 
memory objects. The client SHOULD ensure that memory overloading is gracefully handled by terminating the parsing 
step before memory limits are reached. The purpose of the maxPrograms parameter is to allow the client to avoid 
this occurrence for the large majority of cases. (See also the explanation of the truncated parameter in 
clause 5.1.2.3, which may be included in the response). 

It is RECOMMENDED that when the server truncates a response, it provide the results that it considers to be the closest 
match to the specified query. 

5.1 .1 .4 Interpretation of Query Predicates 

This clause defines the data model that is used to describe how the server processes the query to build its response. This 
model is necessary to explain the way in which queries operate across tables. It does not imply an underlying 
implementation, nor does it imply that a response must strictly satisfy the relational calculus definition given here. 

The data model described in this clause is purely a tool to describe how queries across tables work. This model uses a 
set of relational tables in order to explain how query predicates SHOULD be interpreted. The data model itself is 
informative. 

When all the query predicates contain f ieldID values belong to the same table (e.g. a query based on Title and 
Keyword fields) the result records that satisfy the query constraints will be matched. If the query predicates contain 
f ieldID values belonging to multiple tables, then the matching result records should satisfy those predicates in all 
the relevant tables. The data model is a tool to explain this behaviour, as it can become complex in the general case. 

Firstly, this data model defines a set of relational tables containing the following records for each fragment that matches 
the query. 

• Content referencing record. Each record corresponds to a Result element and the table is uniquely keyed 
with a CRID. 

• Program information record. Each record corresponds to a Programinf ormation element and the table is 
uniquely keyed with a CRID. 

• Group information record. Each record corresponds to a Groupinf ormation element and the table is 
uniquely keyed with a CRID. 

• Broadcast event record. Each record corresponds to a BroadcastEvent or a ScheduleEvent element, 
and can be assigned a CRID. 

• On demand programme record. Each record corresponds to an OnDemandProgram element and can be 
assigned a CRID. 
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• Service information record. Each record corresponds to a Serviceinf ormation element and is uniquely 
keyed with a serviceld. 

• Review record. Each record corresponds to a Review element and is associated with a CRID. 

• Segment information record. Each record corresponds to a Segment Informat ion element and is 
associated with a CRID. 

• Segment group record. Each record corresponds to a SegmentGroupInf ormation element and is 
associated with a CRID. 

Note that, with one exception: the "Content referencing record", these records correspond exactly to the fragments 
defined in part B of the Metadata Specification. Within each record the data is not flat (i.e., there are nested and 
repeated data structures) so in practice this would be a poor relational model for TV-Anytime . 

We now define a combined table formed by performing a sequence of full outer joins as follows: 

1) The service information and broadcast event tables are joined based upon the service Id field. 

2) The service information and on demand programme tables are joined based upon the serviceld field. 

3) The two resulting tables, and all the other tables, are joined based upon the CRID field to leave a single 
combined table. Since the join operation (Cartesian product) is commutative and associative, the order in 
which this join is performed is not significant. 

Each row of the combined table is termed a "result record". A result record has the following properties: 

• There can be many result records containing the same value in the CRID field. 

• A result record may have no entries for a particular field or set of fields. This is equivalent to saying that not 
all types of metadata and metadata tables will be available for every programme. 

• The same fragment can appear in multiple result records. 

• Each field within a result record can be uniquely identified using a f ieldID value. 

5.1 .1 .5 Definition of server behaviour 

This clause defines the server's behaviour to a query that is assumed by the data model. The server SHOULD return a 
response containing content referencing and/or metadata fragments based upon the predicates in the 
QueryConstraints that satisfy the query. 

The server SHALL return a response that contains only the tables specified by the RequestedTables parameter, 
based on the rules defined in clause 5.1.1.2 

Each fragment SHALL be encapsulated in either a TVAMain or ContentReferencingTable element. The 
complete response SHALL contain either one TVAMain element, one ContentReferencingTable element or 
one instance of both TVAMain and ContentReferencingTable. The response SHALL have duplicated 
fragments removed. 



5.1.2 Response Format 



A get_Data response contains an XML instance document containing zero or one instance of the following 
elements: 

• TVAMain. 

• ContentReferencingTable. 

• InvalidFragments. 
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< element name="get_Data_Result " tYpe="tns : get_Data_Re suit Type" /> 
<complexType name="get_Data_Re suit Type "> 
<sequence> 

<element name="TableSortingInf ormation" 

type="tns : RequestedTablesType" minOccurs="0" /> 
<element ref ="tva : TVAMain" minOccurs="0"/> 

<element ref ="cr : ContentReferencingTable" minOccurs="0"/> 
<element name="InvalidFragments " 

type="tns : InvalidFragmentsType" minOccurs=" " /> 
</sequence> 

<attribute name="serviceVersion" type="unsignedlnt" use="required"/> 
<attribute name="truncated" type="boolean"/> 



Name 


Definition 


TVAMain 


An element inside which all metadata items defined in 
TS 102 822-3-1 [12] are instantiated. 


ContentReferencingTable 


An element inside which all metadata items defined in 
TS 102 822-4 [14] are instantiated. 


InvalidFragments 


Represents list of invalid fragments using the 
InvalidFragmentsType type. See clause 5.1 .2.4 for a 
definition of this type and how it is used. 


ServiceVersion 


This parameter indicates the version of the get_Data 
operation's capability description. See clause 5.1 .2.2. 



truncated When this attribute is true, it indicates that the result of the query 

has been truncated because the number of results exceeded the 
maxPrograms attribute specified in the request or the server was 
not able to return all the results. See clause 5.1 .2.3. 



The instance document returned MUST be XML Schema vaHd with respect to the appropriate metadata and content 
referencing schemas. Furthermore, each instance document MUST contain the appropriate TVAlDType type to allow 
complete dereferencing of all TVAlDRef Type nodes within the instance document (e.g. if a Schedule is included, 
the Serviceinf ormation entry, referenced via the servicelDRef, must also be present). 

5.1 .2.1 Indicating the sorting of the response 

The TableSortinglnf ormation element SHALL be included in any response where a sort has been performed 
on the response. 

The first Sort Criteria element defines the first field by which the response has been sorted. Each subsequent 
Sorter iter ia element (if any) defines the next levels of sorting that has been applied. 

For example, the following XML snippet shows a response that has been sorted by service URL and then by published 
time (note that the syntax is the same as that used to specify the sorting in the query). 

<TableSortingInf ormation> 

< Table type="ProgramLocationTable"> 

<Sort Criteria f ieldID="tvaf : ServiceURL" /> 
<Sort Criteria f ieldID="tvaf : PublishedTime" /> 
</Table> 
< /Table Sort ingin format ion> 



5.1 .2.2 Indicating the service version 

The ServiceVersion attribute MUST be included in the response. This parameter indicates the version of the 
get_Data operation's capability description. When the version is updated a client can retrieve a new capability 
description for the metadata service (see clause 7. 1 for more explanation on how this parameter is used). Note that the 
serviceVer s ion attribute indicates nothing about the syntax version in the response (which can be inferred from 
the XML namespace), or the version of the metadata data in the result (metadata version information is indicated using 
the f ragmen tVers ion attribute). 
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5.1 .2.3 Truncating the result set 

If the OPTIONAL truncated attribute has the value "true", the records returned do not represent the entire query 
result set. This is either a result of the inclusion of the maxP r ogr ams attribute in the request, or as a result of the 
server being overloaded. The actual limit used in the latter case is server specific, but in general should be a sufficiently 
large number so as to not normally be an issue. No behaviours such as paging mechanisms are defined for retrieving 
more data after a truncated limit, as this requires more complex client and server implementations (since state must be 
maintained between queries), and would be complex when the server's database is being asynchronously updated. The 
intent is to support the average query, while at the same time allowing servers the leeway required to be able to manage 
adequate performance. 

A very large number of responses is usually an indication that the query was insufficiently specific. In most cases, it is 
possible to refine the query by the alteration of the original parameter set. If truncation occurs as a result of flexible 
interpretation of the query, it is RECOMMENDED that the server falls back to strict interpretation of the query in order 
to reduce the number of responses. 

5.1 .2.4 Updating the result set 

The f ragmentVersion and f ragmentid identifiers MAY be placed at the fragment level in the get_Data 
response (as defined by the TS 102 822-3-1 [12]). If included, this allows the client to request and update individual 
fragments. A client may cache fragment version information and be able to ignore future instances of the same metadata 
if the fragment version number has not been incremented. TV-Anytime metadata in the bi-directional environment MAY 
be updated by the unit of fragments based on the f ragementID and/or f ragmentVersion defined in 
TS 102 822-3-1 [12]. To support the metadata updating in the bi-directional environment, the f ragmentVersion 
has the following additional validity constraints. 

The f ragmentVersion attribute SHOULD be either one of an 8-digit or 14-digit unsigned integer. When it is an 
8-digit integer, it SHOULD follow the format of YYYYMMDD and represents the last updated date of the fragment. 
When it is an 14-digit integer, it SHOULD follow the format of YYYYMMDDhhmmss and represents the last updated 
date and time. YYYY represents year in four digits, MM represents month in two digits, DD represents day of the 
month in two digits, hh represents hour in two digits (using a 24 hour clock), mm represents minute in two digits, and ss 
represents second in two digits. 

If a receiver wants to update a fragment received by the uni-directional link using the bi-directional link it should make 
a request for the same fragment with a fragmentVersion with a later date than it receives the fragment by the uni- 
directional link. 

The server indicates its support for this updating mechanism using the capability description, as described in clause 7.1. 

If the request for a f ragmentID does not include the fragmentVersion, the server shall return its latest version of 
the fragment. 

<complexType name=" InvalidFragmentsTYpe"> 
<sequence> 

<element name="Fragment " minOccurs="0" maxOccurs="unbounded"> 
<complexType> 

OttributeGroup ref ="tva : fragment Identification" /> 
</complexType> 
</element> 
</sequence> 
</complexType> 

Name Definition 

InvalidFragmentsType An InvalidFragmentsType is used to express invalid 

fragment lists. It contains one or more Fragment elements. 
Fragment Identifies an invalid fragment using the 

f ragmentidentif ication attributeGroup (as defined in 
TS 102 822-3-1 [12]). The meaning of fragment id and 
fragmentVersion in this Context Js described in this clause. 
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When the InvalidFragments element is included in the get_Data_Result element, the client SHOULD 
delete the fragments saved in the local storage identifiable by the fragment ID and/or f ragmentVersion listed 
in the InvalidFragments element. 

A fragment ID can be reassigned to other fragments by the publisher, when the original fragment became invalid 
and is deleted. When a fragment ID is reused, to ensure the uniqueness of the fragment ID, the server is expected 
to include the reassigned f ragmentID and the f ragmentVersion representing the deleted date or the last 
modified date of the InvalidFragments element, whenever the requested f ragmentVersion is smaller than 
the f ragmentVersion of the deleted fragment. 



5.2 submit_Data Operation 



The submit_Data operation is much simpler than the get_Data operation. In this version of the specification, its 
usage is limited according to the constraints outlined in clause 3.1.2. 

5.2.1 Usage and user preference data submission policy (informative) 

TV-Anytime phase one technical specifications limit the data that can be submitted to a defined (in clause 3.1.2) set of 
anonymous profile data that has been created via manual input or intelligent agents based on usage of services and 
content. It is out of scope for the device to send "all" usage data to "all" potential service providers known to the PDR 
for Phase One because no authenticated return channel rights management process has been specified yet. 

The TV-Anytime Forum respects and embraces the basic rights of all viewers and providers. These include preserving 
the basic right of a content consumer to privacy and acknowledging the legitimate rights of all participants such as 
content creators and providers, service providers, advertisers and network operators. 

It is the content consumer's decision as to the amount of privacy invasion and profiling capabilities done by these 
participants, and will be allocated by the content consumer to a vendor or service provider at his/her discretion. 

Providers that accept the content consumer's choice to allocate to them the responsibility (partial or in full) to profile 
him/her, through a contract with a service/technology/content provider, will adhere to strict privacy regulations. A 
computer readable representation of this policy (which could be rendered for the content consumer) may be provided as 
part of the describe_submit_data operation, see clause 7.2. The policy regulation will effectively eliminate 
breaches of security of the collected private information in order to avoid any use of it that was not explicitly permitted 
by the end-consumer. 

Providers of content wish to know how their content is performing as far as the consumer is concerned. Business 
decisions may be made as a result (cancel the scheduling of a programme because the viewers don't like it; advertisers 
will want to know viewers numbers, etc). 

An anonymised subset of the UsageHistory table may be submitted if this functionality has been enabled by the 
consumer. Anonymity must be guaranteed so that no detail about the individual will be sent. 

This will enable service providers and broadcasters the ability to analyze aggregated viewer preferences and allow them 
to make business decisions based on their performance in these areas. 



5.2.2 Request Format 



<element name="submit_Data" type="tns : submitDataType"/> 
<complexType name=" submitDataType " > 

<sequence> 

<element name="UsageHistory" type="mpeg7 :UsageHistoryType"/> 

</sequence> 
</compIexType> 

The input to the submit_Data operation simply uses the mpeg7:UsageHistoryType which is part of 
the UserDescription defined in TS 102 822-3-1 [12], and therefore has the same semantics. 
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5.2.3 Response Format 



<element name="submit_Data_Result " 


tYpe= 


"tns 


submit_D 


ata_ 


Result 


'/> 




<complexTYpe name= 


= "submit_Data_ 


_Result"> 














<attribute name= 


="serviceVersion" 


tYpe= 


"unsignedint " 


use 


="requ 


ired' 


/> 


</complexTYpe> 





















The submit_Data response MUST contain some indication of the current version of the capabihty description. This 
allows receivers to update the capability description without having to download the capability description each time 
the submit_Data operation is used. 



Transport Protocol 



SOAP [9] and HTTP [5] are used for delivering TV-Anytime XML data over the IP networks, since this combination is 
very well suited to the point-to-point, request-response nature of the TV-Anytime operations. The exact usage of SOAP 
and HTTP is given in the next two clauses. Figure 4 provides a semantic representation of the network stack. 



TV-Anytime XML 



OPTIONAL 
binary encoding 



OPTIONAL 
security layer 



SOAP 



HTTP 



TCP 



IP 



Figure 4: The bi-directional networit transport stacl< 
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This architecture results in HTTP messages of the following form: 

POST /tva/md-service HTTP/1.0 

Host: www.example.com 

Content-Type: text/xml; charset="utf-8 " 

Content-Length: nnnn 

Accept-Encoding : deflate 

SOAP Act ion: "get_Data" 

<?xml version="l .0" encoding="UTF-8 " ?> 

<Envelope xmlns=" http://schemas.xmlsoap.org/soap/envelope/"> 
<BodY> 

<get_Data xmlns="http : //www . TV-Anytime . org/2002/ll/transport" 

xmlns:tvaf="http: //www. ri/-Anytime. org/2 002/ 11 /transport /fieldlDs "> 
<QueryConstraints type="OR"> 

<Predicate f ieldID="tvaf : GRID" 

f ieldValue="crid : //example . com/f oo" /> 
<Predicate f ieldID="tvaf : GRID" 

f ieldValue="crid: //example . com/ bar" /> 
</ Que ry Cons traints> 
<RequestedTables> 

<Table type="ContentReferencingTable"/> 
</RequestedTables> 
</get_Data> 
</Body> 
</Envelope> 

Figure 5: Example HTTP request 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
Content-Encoding: deflate 

<?xml version="l .0" encoding="UTF-8 " ?> 

<Envelope xmlns = "http : //www . w3 . org/2 002 /0 6/soap-envelope"> 
<Body> 

<get_Data_Result xmlns=" http : //schemas . xmlsoap . org/ soap/ envelope/ "> 
<ContentRef erencingTable version=" 1 " 

xmlns="http : //www . TV-Anytime . org/2002 /0 6/ContentReferencing"> 
<! — ... etc. — > 
</ContentReferencingTable> 
</get_Data_Result> 
</Body> 
</Envelope> 

Figure 6: Example HTTP response 

6.1 SOAP 

The following usage of SOAP is mandated: 

• TV-Anytime metadata services will provide an HTTP binding, and may support other transport bindings where 
appropriate. 

• SOAP supports different messaging styles, but is most commonly used for Remote Procedure Calls. 
TV-Anytime does not use remote procedure call messaging style, since this implies that every parameter must 
be included in a procedure call, which is not appropriate for TV-Anytime operations that have several optional 
parameter types. However, the remote procedure call convention of naming the root element in the SOAP 
body according to the name of the operation is followed. 



• 



SOAP encoding is not used in the request or the response (i.e. the element in the root of the SOAP body will 
belong to the TV-Anytime transport types namespace, urn:tva:transport:2002). Servers will reject any request 
that arrives with a SOAP encoding attribute with the appropriate SOAP Fault. 
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• The SOAP Actor feature is not supported and servers will reject any request that arrives with a SOAP Actor 
attribute in the SOAP Header with the appropriate SOAP Fault. 

• The following clause defines application specific fault conditions to be used in the SOAP Fault element. 
This usage of SOAP is more formally defined using the WSDL interface definition that can be found in annex A. 

6.2 Error Codes 

The first line of error reporting is governed by the SOAP specification [9]. SOAP fault reporting and fault codes will be 
returned for most invalid requests or any request where the intent of the caller cannot be determined. 

In a manner consistent with the SOAP processing rules, HTTP status codes will be used for communicating status 
information in HTTP. As is the case for SOAP, success reporting will use a 200-status code to indicate that the client's 
request including the SOAP component was successfully processed. 

The ErrorReport element is defined to allow servers to report application-level errors that are specific to 
TV-Anytime metadata services. In accordance with the SOAP specification, if the content of the SOAP message's Body 
cannot be processed successfully, the SOAP fault MUST contain a detail element (which in turn contains an 
ErrorReport). Note that the inability to process a well-formed Body element is also termed an "application-level 
error", since the error cannot be detected by the SOAP processor and instead relies on application-level knowledge. The 
error report contains error information that includes descriptions and a code that can be used to determine the cause of 
the error. Errors that arise due to problems with in the HTTP layer or SOAP layer (e.g. the SOAP message does not 
conform to the SOAP specification) should be reported using the error mechanisms provided by those layers and MUST 
NOT be reported inside a SOAP fault's Detail element. 

TV-Anytime application-level errors SHOULD be conveyed using standard HTTP status codes, where a 500-level code 
indicates a server-induced error. In such cases, the metadata service MUST issue an HTTP 500 "Internal Server Error" 
response and return an ErrorReport inside a SOAP fault report. 

Any errors detected in the request will invalidate the entire request, and cause an ErrorReport to be generated 
within a SOAP fault as described below. A server MAY report multiple errors, although there is no requirement for the 
metadata service to continue processing the request after detecting the first error. In accordance with the SOAP 
specification, additional application response elements SHOULD NOT be included in the Body of the SOAP request. 
In other words, it is not possible for the server to indicate an error condition and also make a best-effort at providing a 
response. 

The ErrorReport element takes the following form: 

<element name="ErrorReport" type="tns : ErrorReportType" /> 
<complexType name=" ErrorReport Type "> 
<sequence> 

<element name="Error" type="tns : ErrorType" maxOccurs="unbounded" /> 
</sequence> 
</complexType> 

<complexType name="ErrorType"> 
<sequence> 

<element name="Reason" type="mpeg7 : TextualType" minOccurs="0" 
maxOccurs="unbounded" /> 
</sequence> 

Ottribute name="errorCode" use="required" type="tns : errorCodeType" /> 
Ottribute name=" fields" type="tns : f ieldIDListType"/> 
</complexType> 

< simple Type name=" errorCodeType "> 
<restriction base="string"> 

<enumeration value="FatalError" /> 
<enumeration value=" InvalidRequest " /> 
<enumeration value=" Unsupported" /> 
<enumeration value="UnrecognizedVersion" /> 
<enumeration value="Unspecif ledError " /> 
<enumeration value="Un support edQueryFie Id" /> 
<enumeration value="UnsupportedSort Field" /> 
<enumeration value=" InvalidFieldID" /> 
<enumeration value=" InvalidFieldValue" /> 
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</restriction> 
</simpleType> 




Name 


Definition 


ErrorReport 


Lists the application level errors that have occurred as a result 
of invoking a metadata service. 


Error 


Describes a single application-level error. 


errorCode 


A REQUIRED string that precisely defines the nature of the 
error. The legitimate values for this string are listed in 
clauses 6.2.1.1 and 6.2.1.2. 


fields 


An OPTIONAL attribute that lists the f ieldiD values related 
to this error. 


Reason 


An OPTIONAL human meaningful description of the error. 



6.2.1 General error conditions 

The following error codes MAY be returned by invoking any of the operations defined in the present document. The 
field attribute is not relevant to these errors, and so SHALL not be present for the following error conditions. 

• FatalError: Signifies that a serious technical error has occurred whilst processing the request. 

• InvalidRequest: The query is well-formed but not valid according to the Schema defined by the present 
document. 

• Unsupported: Signifies that the metadata service does not support an optional feature that is required in order 
to correctly process the request. A possible reason for this error is that the client has assumed a functionality 
that is at odds with the functionality described in the capability description. 

• UnrecognizedVersion: Signifies that the namespace of the child element inside Body element of the request 
(e.g. the urn:tva:transport:2002 namespace) is unsupported by this metadata service. 

• UnspecifiedError: Signifies any other error. 

Error conditions are not mutually exclusive and some are special cases of others (e.g. some of the get_Data error 
conditions below are special cases of the Unsupported error). A metadata service SHOULD provide the most specific 
error code that is appropriate to the error. 

The next clause defines error codes that are specific to the get_Data operation. No specialized error conditions are 
defined for the submit_Data, describe_get_Data, and describe_submit_Data operations. 



6.2.2 get_Data operation error conditions 



When any of the following errors are returned, the operation SHALL return a field attribute listing the field identifiers 
that caused the error to occur. 

• UnsupportedQueryField: A query contains a f ieldID value that is no supported by the metadata service. 
When this error is returned, the operation SHALL return a field attribute listing the unsupported fields. 

• UnsupportedSortField: A sort is requested using a field for which sorting is not supported by the metadata 
service. 

• InvalidFieldID: A f ieldID in any type of predicate or sortCriteria element contained a field 
identifier that is neither in the TV-Anytime defined field identifier list, nor in the field identifier list given by 
the service capability description of this operation. 

• InvalidFieldValue: The f ieldValue in a BinaryPredicateBagType element contains a string that 
is not appropriate to the f ieldID in that predicate. This might be because the field being queried is an 
enumerated type or because the field has syntactic restrictions (e.g. the tvaf : CRID field). 
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If a query requests a ContentRef erencingTable and contains one or more GRID fields in the query, the 
metadata service should be careful to behave correctly when it is unable to provide location resolution data for the 
CRID(s). In particular, if the CRID is syntactically correct but no content referencing information is available a 
Result element should be returned for the CRID with the status flag set appropriately. No error condition should 
be raised. In general, it is not an error condition if a metadata service is simply unable to provide appropriate metadata 
in response to a query. 

HTTP/1.1 200 OK 

Content-Type: text/xml; charset="utf-8 " 
Content-Length: nnnn 
Content-Encoding: deflate 

<?xml version="l .0" encoding="UTF-8 " ?> 

<Envelope xmlns = "http : //www . w3 . org/2 002 /0 6/soap-envelope"> 
<BodY> 
<Fault> 

<faultcode>Client</ fault code> 
<detail> 

<ErrorReport xmlns="urn : tva : transport : 2002 " 
xmlns : tvaf ="urn : tva : transport :fieldIDs:2002"> 

<Error errorCode="UnsupportedQueryField" f ields="tvaf : Title "> 
<Reason xml : lang="en"> 

Searching on Title field is unsupported</Reason> 
</Error> 
</ErrorReport> 
</detail> 
</Fault> 
</Body> 
</Envelope> 

Figure 7: Example of response indicating an error 

6.3 HTTP 

• The HTTP server and client MUST fully support HTTP/I .0 [5] . 

• The client MUST always send the HTTP/1.1 defined Host header (which is defined in clause 14.23 of 
HTTP/1.1 [8]). 

• The HTTP client and server negotiate a suitable compression using the Accept-Encoding header. Therefore, 
both the client and server MUST support the Accept-Encoding header (which is defined in clause D.2.3 of 
HTTP/1.0 [5], but is not required by that specification). 

• Clients MUST be prepared to follow HTTP redirects (according to clause 9.3 of HTTP/1 .0 [5]) to allow server 
fall-over and load-balancing. Note that contrary to HTTP/1 .0, redirections should be followed automatically, 
without user intervention, even though the POST method is being used. 

• The SOAPAct ion HTTP header field SHOULD be set to the name of the operation being called. 



6.4 Encapsulation of Metadata 



In all cases, the request and response data form a single, valid XML instance document. In general, these instance 
documents are self-describing and need no further encapsulation. However, the metadata encapsulation for the 
get_Data operation is defined in more detail. 

6.4.1 Encapsulation of get_Data response 

The content of the SOAP envelope is a TVAMain element and/or ContentRef erencingTable, as specified in 
clause 5.1.2. These XML instance documents effectively provide an encapsulation format for the fragments they 
contain. The context path of each fragment is implicit from the fragment's location in the instance document. The 
f ragmentVersion and f ragmentid identifiers MAY appear at the fragment level (as defined in 
TS 102 822-3-1 [12]). 
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Each get_Data operation can be considered to provide a single metadata description (the term "metadata description" 
is defined in TS 102 822-3-2 [27]), from which each query selects a metadata subset. Thus, the content of the TVAMain 
fi-agment (see clause 4.3.1.1 of TS 102 822-3-2 [13]) is fixed at a given moment in time. The version attribute of the 
TVAMain fragment applies only to the fragment itself and not to its child fragments. Consequently, although this 
fragment is sent with every response, a client only needs to update its cache of the fragment (if any) when the 
TVAMain element's version attribute increases. 



6.5 Encoding of Metadata 



Servers MUST support UTF-8 textual encoding for all requests and responses, and MAY support other encodings, in 
which case the encoding MUST be indicated in the XML header according to clause 4.3.3 of the XML specification [1]. 
If an encoding is so indicated it MUST be consistent with the encoding indicated in the HTTP/1.0 [5] Content-Type 
header (e.g. see figure 5). 

For efficiency reasons, HTTP clients and servers SHOULD support at least one well-known compression format. 
Clients SHOULD indicate the compression formats they understand using the Accept-Encoding HTTP header. The 
HTTP server SHOULD use the most efficient encoding that is understood by both the client and server, and indicate 
this in the HTTP response using the Content-Encoding header. It is RECOMMENDED that both TV-Anytime HTTP 
cUents and servers support the use of the deflate Content-Encoding type (as defined in clause 3.5 of HTTP/1.1 [8]). 

Other compression formats may be supported, including the use of BiM specified in Annex E. In all cases, the use of 
transport layer compression MUST be transparent to the SOAP processor and higher layers. 



6.6 Metadata Service Security 



The TV-Anytime phase 1 set of specifications offers clients guaranteed integrity of the metadata delivery from an 
authenticated server. This technology is described in TS 102 822-7 [16]. A metadata server that supports the 
TS 102 822-7 [16] specification for integrity checking SHALL be capable of communicating with clients that 
implement TS 102 822-7 [16] and with clients that do not. If TS 102 822-7 [16] is used and the server wishes to identify 
the source of the request, it SHOULD do so using HTTP Basic Authentication (negotiated according to HTTP/1.0 [5]). 
Any additional security services are not mandated or prevented by the present document and fall outside its scope. 



7 IVIetadata Service Capability Descriptions 

For each TV-Anytime get_Data or submit_Data operation that is provided, there is a corresponding operation, 
describe_get_Data or describe_submit_Data. These two operations (an operation, X, and its 
corresponding describe_X operation) together form a port (see annex A). Since a port always has a single binding and 
endpoint, the URL of the operation, X, and its corresponding describe_X operation must be the same. A describe 
operation is responsible for returning a capability description for the corresponding operation of the same port. A 
describe operation has no input parameters. 

7.1 describe_get_Data 

The get_Data capability description provides the following type of information about the operation. 

Human-readable descriptive information about the operation. 

The types of metadata tables available. 

If content referencing information is available, the Resolving Authority Records for that get_Data 
operation. 

If programme metadata is available, the CRID authorities known by the server for that type of metadata. 

If scheduling information is available, the content delivery services know by that server. 

If metadata queries are possible, the query fields that are allowed for each table. 
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• If sorting is possible, the sort fields that are supported for each table and the type of collation on which the sort 
is based. 

• The ability of the operation to deliver update and invalidation information. 

The format of the capability description is as follows. 

<element name="describe_get_Data_Result " 

tYpe="tns : describe_get_Data_Result " /> 
<complexType name="describe_get_Data_Result "> 
<sequence> 

<element name="Name" tYpe="string" minOccurs="0"/> 

<element name="Description" type="mpeg7 : TextualType" minOccurs="0" 

maxOccurs="unbounded" /> 
<element name="CollationURI" type="anyURI " minOccurs=" " /> 
<element name="ExtendedFieldList" type="tns :FieldIDDef initionListType" 
minOccurs=" "> 
<key name="UniqueExtendedFields "> 

<selector xpath="tns : FieldlDDef inition"/> 
<field xpath="@fieldID"/> 
</key> 
</element> 
<element name="AuthorityList" type="tns : AuthorityListType" 

minOccurs=" " /> 
<element name="AvailableTables" type="tns : AvailableTableListType"/> 
<element name="UpdateCapability " type="tns : updateCapabilityType" 
minOccurs=" " /> 
</sequence> 

<attribute name="serviceVersion" type="unsignedlnt" use="required"/> 
</complexType> 



Name Definition 

serviceVersion A REQUIRED parameter that MUST equal the version 

number returned as part of the corresponding operation's 
result. The intention of this number is to make the client 
aware when an operation has been upgraded (e.g. can be 
searched on new channels or for new resolution 
authorities) and to refresh the cached capability 

description information (if any). 

Name OPTIONAL name of the metadata service, suitable for 

display to a user. 

Description OPTIONAL textual description of the metadata service, 

suitable for display to a user. This allows an application 
exploiting the metadata service to indicate to the user 
information about the metadata service that she is using 

(e.g. "Specialists in movie information and reviews"). 

CollationURi OPTIONAL URI that indicates the name of the collation 

that sorts are based on. If no sorting is supported this field 
is meaningless and SHOULD be omitted. If sorting is 
supported and this field is not present then sorting MUST 
be based on the Default Unicode Collation Element Table. 
The present document does not define the form of the 
URI, or any means of specifying or obtaining a collation. 
Regional bodies may define suitable URIs and their 

associated collations, as appropriate to their locale. 

ExtendedFieidList Provides a list of f ieidiD values and their associated 

field using the FieldlDDef initionListType. Used 
for fields that the server wishes to support but are not 
allocated a f ieidiD by the TV-Anytime Forum (see 

clause 5.1.1.1.1). 

AuthorityList An OPTIONAL list of authorities for which this operation 

can provide metadata for all the table types it is capable 
of delivering. See also clause 7.1 .1 . 
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Name Definition 



AvailableTables A REQUIRED description of the types of data tables that 

can be returned by this get_Data response. At least 
one Table entry MUST be present. For each table, the 
fields that can be queried on and sorted on are specified. 
Depending on the type of table, other descriptive 

information is sometimes included. 

updateCapabiiity An OPTIONAL update capability description to indicate 

the server's capability of update capability as defined in 
clause 5.1 .2.4. When this element does not exist, the 
server does not support either versioned update nor the 
invalid fragment notification. See clause 7.1 .4 for more 
details. 



For examples of get_Data capability descriptions see annex D. 

7.1 .1 Use of the AuthorityList element 



<complexType name="AuthorityListType"> 

<sequence> 

<element name="Authority" type=" string" maxOccurs="unbounded"/> 

</sequence> 
</complexType> 



Name 


Definition 


Authority Li St Type 


A definition of a list of one or more Authority 
elements. 


Authority 


Specifies a single authority for whose CRIDs the 
operation is able to provide TV-Anytime data. 



The AuthorityList element can be instantiated in two locations: 

• As one of the elements at the top level of the capability description. In this case, the server is able to provide 
data on the listed authorities for all of the data table types that are listed in the AvailableTables element. 
If the capability description indicates that a ContentRef erencingTable can be returned, then there 
SHOULD be a ResolvingAuthorityRecord for each of the authorities listed in the top level 
AuthorityLi St. This element allows a server to specify its list of supported authorities, without the need 
to repeat this information for every table that it supports. 

• As one of the children elements of a table listed in the AvailableTables element. In this case, the server 
is able to provide data of the type indicated by the Table elements xml schema declared type attribute for 
this authority. 

NOTE: The capability description indicating that a certain type of metadata is available for a certain authority 
does not necessarily mean that the server will be able to provide that metadata for any particular GRID. 

7.1.2 AvailableTables information 

This element describes which table types the get_Data operation is capable of returning. Depending upon the table 
type, each entry in the list (a Table element) can contain a different child element. These child elements contain 
descriptive information that is relevant to that table type. 

<complexType name= " Ava i 1 ab 1 eTable List Type "> 
<sequence> 

<element name="Table" type="tns : AvailableTableBase" 
maxOccurs=" unbounded" /> 
</sequence> 
</complexType> 

<complexType name="AvailableTableBase" abstract="true"> 
<sequence> 
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<element name="AuthorityList" type="tns : AuthorityListType" 
minOccurs=" " /> 
</sequence> 

<attribute name="canSort" type="tns : f ieldIDListType"/> 
<attribute name="canQuery" type="tns : f ieldlDListType" /> 
</complexType> 

<complexType name="ContentRef erencingTable"> 
<complexContent> 

<extension base="tns : AvailableTableBase"> 
<sequence> 

<element ref ="rar : ResolvingAuthorityRecordTable" /> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 
<complexType name="Classif icationSchemeTable"> 
<complexContent> 

<extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 

<complexType name="ProgramInf ormationTable"> 
<complexContent> 

< extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 

<complexType name= "Groupin format ionTable"> 
<complexContent> 

<extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 

<complexType name="ProgramLocationTable"> 
<complexContent> 

<extension base="tns : AvailableTableBase"> 
<sequence> 

<element name="AvailableLo cat ions "> 
<complexType> 
<sequence> 

<element name="Availability" type="duration" minOccurs="0"/> 
<element name="ServiceURL" type="anyURI " 
maxOccurs=" unbounded" /> 
</sequence> 
</complexType> 
</element> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 

<complexType name="ProgramReviewTable"> 
<complexContent> 

< extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 

<complexType name= "Segment In formationTable"> 
<complexContent> 

<extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 

<complexType name= "Service In formationTable"> 
<complexContent> 

< extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 

<complexType name= "Credit I nformationTable"> 
<complexContent> 

< extension base="tns : AvailableTableBase" /> 
</complexContent> 
</complexType> 
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Name Definition 



Table Indicates that a particular table is available from this 

get_Data operation and encapsulates information 
relevant to querying that table. All instantiations of this 
element will be derived from the base type, 
AvailableTableBase, which can have the following 

three attributes. 

xsi : type This is the xml schema declared type attribute which is 

used to indicate the type of table where xsi is used as the 
namespace qualifier for xml schema. Can take the 
following values: ContentReferencingTable, 
ProgramlnformationTable, GrouplnformationTable, 
ProgramLocationTable, ProgramReviewTable, 
SegmentlnformationTable, ServicelnformationTable, and 

CreditslnformationTable. 

canQuery List of f ieidiD values indicating the query fields that 

can be accepted by this operation. The order of the fields 
is not significant. All tables that can be queried on (see 
clause 5.1 .1 .1 .4), except the 

ServicelnformationTable, IVIUST support querying 
using the grid field. Hence, this attribute is meaningless 
when combined with a table of type 
"ContentReferencingTable" and 
"CreditslnformationTable". If this attribute is not present 

no other type of querying is supported for this table. 

canSort List of f ieidiD values indicating the query fields that 

can be used for sorting (as indicated using the 
SortCriteria parameter in a query). For every field 
that a server declares that it supports sorting, it SHALL 
support both ascending and descending sorting of that 
field. If this attribute is not present, sorting is not 
supported for this table. The order of the fields is not 

significant. 

AuthorityList An OPTIONAL list of authorities for which this operation 

can provide metadata of the type included in this table. 

See also clause 7.1.1. 

ResolvingAuthorityRecordTable As defined in TS 102 822-4 [14]. This element is 

REQUIRED if Table has the type 
"ContentReferencingTable". Tables of this type SHOULD 
NOT include an AuthorityList (since the 
ResolvingAuthorityRecordTable indicates which 
authorities content referencing information is provided 

for)^ 

AvailableLocations This element is REQUIRED if the Table has the type 

"ProgramLocationTable". The element specifies the types 
of programme location related queries that can be 

answered by the server. 

Availability An OPTIONAL duration that indicates to the client the 

time window over which the schedule information is 
available (e.g. "it is possible to query these channels for 

the next 10 days only"). 

ServiceURL The Content services for which scheduling information is 

available (corresponds to the ServiceURL element that 
can be included in a ServicelnformationTable). 



7.1 .2.1 Operations that can deliver content referencing information 

If the server is capable of delivering content referencing information then the description will include a list of Resolving 
Authority Records describing the resolution services offered by this server. This allows a client to establish whether a 
particular CRID may be resolved using the metadata service. 
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7.1 .2.2 Operations that can deliver programme metadata 

If the server is capable of delivering programme metadata then the description will include a list of GRID authorities for 
which metadata is available. 

If the server is capable of delivering scheduling information (ProgramLocationTable), a list of the content service 
URLs (e.g. broadcast channels, IP multicast services, or on-demand contents servers) known by this metadata service is 
also provided. Using this data a receiver can determine whether any of the programmes being described by this server 
are being offered using content delivery services that are actually available to the receiver. Based upon this information 
a receiver can construct queries for scheduling information, such as the one shown in example 7 in annex C. 

7.1.3 Extended Field List 

If a metadata service wishes to support querying or sorting on fields that are not allocated fieldlDs by the 
TV-Anytime Forum, it has to define these field using its own ExtendedFieldList. This allows a get_Data 
operation to provide searching and sorting functionality that is specialized to the metadata available to that metadata 
service. For example, if a metadata service specializes in providing segmentation information for the highlights of 
sports programmes, the metadata service can define extended fields for the Title and Synopsis of segments so as to 
allow receivers to make refined queries for segmentation information. 

7.1 .4 Description of update capabilities 

There are two OPTIONAL features whose support shall be independently indicated using this part of the capability 
description. 

<complexType name="updateCapabilitYTYpe"> 

Ottribute name="versionRequest " type="boolean" def ault="true"/> 
Ottribute name="invalidResponse" type="boolean" default="true"/> 

</complexType> 



Name Definition 

updateCapabilityType Defines a container of versionRequest and 

invaiidResponse attributes, whicli can specify 
whether the server can provide versioned metadata and 

lists of invalid fragments. 

versionRequest An attribute of Boolean value to indicate the server's 

capability of handling version requests. 

invaiidResponse An attribute of Boolean value to indicate whether the 

server is able to provide invalidated fragments when they 
are no longer valid or removed. 



7.2 describe submit Data 



The describe_submit_Data capability description provides a metadata service with the ability to describe the 
usage and preference information that it wishes to receive. It can optionally specify the privacy policy that will be used 
when user centric data is submitted to this metadata service. 

<complexType name="describe_submit_Data_Result "> 
<sequence> 

<element name="Name" type="string" minOccurs="0"/> 

<element name="Description" type="mpeg7 : TextualType" minOccurs="0" 

maxOccurs="unbounded" /> 
<element name="RequestedTables" type="tns :RequestedSubmitTablesType"/> 
<element ref="p3p : POLICY" minOccurs="0"/> 
</sequence> 
</complexType> 

<complexType name="RequestedSubmit Table sType"> 
<sequence> 

<element name="Table" maxOccurs="unbounded"> 
<complexType> 
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Ottribute name="tYpe" use="required"> 
< s imp le Type > 

<restriction base="string"> 

<enumeration value="UserP references " /> 
<enumeration value="UsageHi story" /> 
</restriction> 
</simpleType> 
</attribute> 
</complexType> 
</element> 
</sequence> 
</complexType> 



Name 



Definition 



Name 



OPTIONAL name of the metadata service, suitable for 
display to a user. 



Description 



OPTIONAL textual description of the metadata service, 
suitable for display to a user. This allows an application 
exploiting the metadata service to indicate to the user 
information about the metadata service that she is using. 



RequestedTables 



The list of tables that this operation wishes to receive. 



p3p:P0LICY 



OPTIONAL element that describes the privacy policy of 
this operation, using the Platform for Privacy Preferences 
[23] specification. 



RequestedSubmit Tables Type 



A list of table elements containing at least one entry. 



Table 



Specifies the type of table requested by the server. 



type 



REOUIRED parameter giving the type of TV-Anytime 
table requested by the server. Can take the values: 
"UsageHistory" or "UserPreferences". 
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Annex A (normative): 

Formal Definition of IVIetadata Services 

This annex provides a WSDL [20] interface definition for all TV-Anytime metadata services. WSDL defines a number 
of terms used to describe web services. The way in which these relate to TV-Anytime metadata services is given below. 

• Operation: All TV-Anytime operations are request-response based, so can be thought of as a type of remote 
procedure call. An example of a TV-Anytime operation is submit_Data or describe_get_Data. 

• PortType: A collection of operations. When given a binding and a concrete endpoint the portType is known 
as a port. All operations in a given port MUST be present (i.e. it is not possible to offer only some of the 
operations in a port) and MUST have the same binding. The TV-Anytime Forum defines two portTypes 
(get_Data and submit_Data), each of which has two operations, the basic functionality (get_Data or 
submit_Data) and the corresponding describe operation (describe_get_Data or 
describe_submit_Data). 

• Binding: A particular protocol binding (e.g. SOAP or HTTP GET) for a. portType. There may be more than 
one binding for each portType. Each one is a different port and offers an alternative means for accessing the 
same portType. A TV-Anytime server could choose to provide other bindings, such as an HTTP POST 
implementation. By mandating a SOAP binding, a minimum level of interoperability is guaranteed. 

• Service: A family ofWSDL ports that are related in some way. A TV-Anytime metadata service can contain a 
get_Data port and/or a submit_Data port. In practice, most TV-Anytime servers will have just one WSDL 
service. However, the server provider could choose to group certain ports together for some reason. (E.g. a 
movie service containing a get_Data port and a submit_Data port, and a children service containing 
just a get_Data port). 

The following document is a WSDL interface definition that defines the behaviour of all TV-Anytime defined web 
services. It plays two roles: 

• The WSDL interface formally specifies the inputs, outputs, encodings and transport bindings used by all 
TV-Anytime web services. The definitions given correspond to the specification of TV-Anytime metadata 
services earlier in this document. 

• Metadata service providers wishing to provide WSDL implementation definitions for their metadata services 
can import this WSDL interface definition. Annex G gives an example of how such a WSDL implementation 
can be referenced from a WS -Inspection description. 

<?xml version=" 1 . 0" ?> 
<def initions 

targetNamespace="urn : tva : transport : wsdl : 2002 " 
xmlns :tns="urn: tva : transport : wsdl : 2002 " 
xmlns : tva="urn : tva : transport : 2002 " 

xmlns : soap="http : //schemas . xmlsoap .org/wsdl/soap/" 
xmlns="http : //schemas . xmlsoap . org/wsdl/ "> 
<documentation> WSDL Service Interface for a TV Anytime web service API. This WSDL 
document defines the API calls for the two types of TV Anytime ports</documentation> 
< import namespace="urn : tva :transport:2002"/> 
< ! -- Basic input and output messages. --> 
<message name="get_Data"> 

<part name="body" element="tva : get_Data"/> 
</message> 
<message name="get_Data_Result "> 

<part name="body" element="tva : get_Data_Result"/> 
</message> 
<message name="describe_get_Data"> 

<part name="body" element="tva : describe_get_Data"/> 
</message> 
<message name="describe_get_Data_Result "> 

<part name="body" element="tva: describe_get_Data_Result "/> 
</message> 
<message name="submit_Data"> 
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<part name="body" element="tva : submit_Data"/> 
</message> 
<message name="submit_Data_Result "> 

<part name="body" element="tva : submit_Data_Result "/> 
</message> 
<message name="describe_submit_Data"> 

<part name="body" element="tva: describe_submit_Data"/> 
</message> 
<message name="describe_submit_Data_Result "> 

<part name="body" element="tva : describe_submit_Data_Result " /> 
</message> 
<message name="ErrorReportMessage"> 

<part name="body" element="tva :ErrorReport"/> 
</message> 

<! — The different types of services (ports) with their inputs and outputs. — > 
<portType name="get_Data_Port "> 
<operation name="get_Data"> 

< input message="tns : get_Data" /> 
<output message="tns : get_Data_Result"/> 
<fault name="error" message="tns : ErroReportMessage" /> 
</operation> 
<operation name="describe_get_Data"> 

<input message="tns : describe_get_Data" /> 
<output message="tns : describe_get_Data_Result " /> 
<fault name="error " message="tns : ErroReportMessage"/> 
</operation> 
</portType> 

<portTYpe name=" submit_Data_Port "> 
<operation name="submit_Data"> 

<input message="tns : submit_Data" /> 
<output message="tns : submit_Data_Result " /> 
<fault name="error" message="tns : ErroReportMessage"/> 
</operation> 
<operation name="describe_submit_Data"> 

< input message="tns : describe_submit_Data" /> 
< out put message="tns : describe_submit_Data_Result " /> 
<fault name="error" message="tns : ErroReportMessage"/> 
</operation> 
</portType> 

< ! -- The bindings: defines how SOAP/HTTP is used to carry the service. --> 
<binding name="get_Data_SOAP" type="tns : get_Data_Port "> 

<documentation>TV Anytime get_Data binding</documentation> 
<soap : binding style="document " 

transport="http : //schemas . xmlsoap . org/soap/http" /> 
<operation name="get_Data"> 

<soap : operation soapAction="get_Data"/> 
<input> 

<soap:body use="literal" parts="body"/> 
</input> 
<output> 

<soap:body use="literal" parts="body"/> 
</output> 
<fault name="error "> 

<soap: fault use="literal"/> 
</fault> 
</operation> 
< ope rat ion name="describe_get_Data"> 

<soap : operation soapAction="describe_get_Data" /> 
<input> 

<soap:body use="literal" parts="body"/> 
</input> 
<output> 

<soap:body use="literal" parts="body"/> 
</output> 
<fault name="error"> 

<soap: fault use="literal"/> 
</fault> 
</operation> 
</binding> 
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<binding name="submit_Data_SOAP" type="tns : submit_Data_Port "> 
<documentation>TV Anytime submit_Data binding</documentation> 
<soap : binding stYle="document " 

t ran sport = "http : //schemas . xmlsoap . org/soap/http" /> 
<operation name="submit_Data"> 

<soap : operation soapAction=" submit_Data" /> 
<input> 

<soap:body use="literal" parts="body"/> 
</input> 
<output> 

<soap:body use="literal" parts="body"/> 
</output> 
<fault name="error "> 

<soap: fault use="literal"/> 
</fault> 
</operation> 
<operation name="describe_submit_Data"> 

<soap : operation soapAction="describe_submit_Data" /> 
<input> 

<soap:body use="literal" parts="body"/> 
</input> 
<output> 

<soap:body use="literal" parts="body"/> 
</output> 
<fault name="error "> 

<soap: fault use="literal"/> 
</fault> 
</operation> 
</binding> 
</definitions> 
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Annex B (normative): 

TV Anytime defined field and contextNode identifiers 

The TV-Anytime fieldID definition scheme which is defined in clause 5.1.1.1.2 is included in the 
tva_fieldID_definitions_v 1 0.xml file. 

The TV-Anytime contextNodelD definition scheme which is defined in clause 5.1.1.1.1 is included in the 
tva_contextNodeID_definitions_v 1 0. xml file . 
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Annex C (informative): 
Examples of get_Data Requests 



This annex gives some simple examples of how a PredicateBag element can be used to represent different types of 
queries. By combining these PredicateBag elements more refined queries can be built up. 



C.1 Requesting data on specific CRIDs 

To retrieve metadata on a particular set of CRIDs, the following query type is used. The type of data returned will 
depend upon the RequestedTables parameter. 



<PredicateBag type="OR"> 

<BinaryPredicate f ieldID="tvaf : GRID" f ieldValue="crid : //example . com/f oo" /> 
<BinaryPredicate f ieldID="tvaf : GRID" f ieldValue="crid : //example . com/ bar" /> 

</PredicateBag> 



C.2 Requesting specific fragments 

To obtain a particular set of fragments, the query takes the following form. 



<PredicateBag type="OR"> 




<BinaryPredicate f ieldID="tvaf : f ragmentID" 


fieldValue="345 67"/> 


<BinaryPredicate f ieldID="tvaf : f ragmentID" 


fieldValue="1234 4"/> 


</PredicateBag> 





The RequestedTable parameter can still be used to sort fragments retrieved in this fashion, but it has no effect on 
the fragments returned (i.e. it does not cause fragments from other tables to be returned also). 



C.3 Searching for the film "Titanic" 

The following search would return any programme with "Titanic" in the title. 



<BinaryPredicate fieldID="tvaf : Title" f ieldValue="Titanic" test="contains"/> 



To refine the query to find a specific "Titanic" programme the following query could be used. The following will only 
return matches that were directed by James Cameron. 



<QueryConstraints> 

<PredicateBag type="AND"> 

<BinaryPredicate f ieldID="tvaf : Title" fieldValue= "Titanic "/> 
<PredicateBag type="AND" contextNode="tvac : Greditsltem"> 

<BinaryPredicate f ieldID="tvaf :Role" fieldValue=" :role:V83"/> 
<BinaryPredicate f ieldID="tvaf : GivenName" fieldValue=" James "/> 
<BinaryPredicate fieldID="tvaf :FamilyName" fieldValue= "Gamer on" /> 
</PredicateBag> 
</PredicateBag> 
</QueryGonstraints> 
<RequestedTables> 

< Table type="ProgramInf ormationTable"> 

<SortGriteria f ieldID="tvaf : GRID" order="ascending" /> 
</Table> 
< Table type="GroupInf ormationTable"> 

<SortGriteria f ieldID="tvaf : GRID" order="ascending" /> 
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</Table> 
</RequestedTables> 



C.4 Searching for a comedy drama that does not star Jim 
Carrey 

The following search will find comedy dramas, but only those that do not involve Jim Carrey as a key character. 



<PredicateBag type="AND"> 
















<BinarYPredicate fieldID="t 


vaf : Genre" 


fieldValue=" : 


content : 3 . 4 . 


11" 


/> 


<PredicateBag negat 


e="true" 


tYpe= 


= "AND 


" contextNode= 


"tvac 


: Credit 


sit 


em"> 


<BinaryPredicate 


fieldID= 


"tvaf 


Role 


" fieldValue=' 


: role 


:V709"/ 


> 




<BinaryPredicate 


fieldID= 


"tvaf 


Give 


nName" fieldValue=" 


Jim"/> 






<BinaryPredicate 


fieldID= 


"tvaf 


Fami 


lyName" fieldValue= 


"Carey" 


/> 




</PredicateBag> 


















</PredicateBag> 



















C.5 Searching for a programme with a rating of more 
than 8 

The following predicate will find only programmes that have been assigned review ratings of more than 8 by the user's 
favorite reviewer, John Green. 



<PredicateBag type="AND" contextNode="tvac :Review"> 

<BinaryPredicate f ieldlD="tva : ReviewerGivenName" f ieldValue=" John" /> 
<BinaryPredicate f ieldlD="tvaf : Re viewer Fami lyName" fieldValue=" Green" /> 
<BinaryPredicate f ieldlD="tvaf : RatingValue" test="greater_than_or_equals" 
fieldValue="8"/> 

</PredicateBag> 



C.6 Searching for a ClassificationScheme Table 

The following predicate will find the ClassificationScheme Uri equals "urn:tva:metadata:cs:TVARoleCS:2002" or the 
CSAHas equals "TVARoleCS". 



<get_Data xmlns=urn : tva 


: transpo 


rt:2002 .. 


. > 










<QueryConstraints> 
















<PredicateBag type= 


"0R"> 














<BinaryPredicate 


fieldlD= 


"CSUri" 












fieldValue 


="urn : tva : metadata 


: cs 


: TVARoleCS 


2002" 


/> 


<BinaryPredicate 


fieldID= 


"CSAlias" 


fie 


ldValue= 


="TVARole 


CS" /> 


</PredicateBag> 
















</QueryConstraints> 
















<RequestedTables> 
















<Table type="Classi 


f ication 


Scheme"/> 












</RequestedTables> 
















</get_Data> 

















The response including the ClassificationSchemeTable would be as below: 



<get_Data_Result ...> 




<TVAMain version=" 2002 928" publisher="TVA-Metadata-Service" 


. . . > 


<Classif icationSchemeTable> 




<Classif icationScheme uri="urn : tva : metadata : cs : TVARoleCS 


2002"> 
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< Import href="urn :mpeg :mpeg7 : cs : RoleCS : 2 001 " /> 
<mpeg7:Term termID="V708"> 

<mpeg7 :Name xml : lang="en">Dubber</mpeg7 : Name> 
</mpeg7 : Term> 

</Classif icationScheme> 
</Classif icationSchemeTable> 
</TVAMain> 
</get_Data_Result> 



C.7 Creating an EPG 

The following search retrieves all the broadcast programmes on three specific channels over a two-day period. 



<PredicateBag type="AND"> 




<BinarYPredicate f ieldID="tvaf :PublishedTime" 




fieldValue="2002-09-26T00:00:00Z" test="greater_than_or_ 


.equals "/> 


<BinarYPredicate f ieldID="tvaf :PublishedTime" 




fieldValue="2002-09-27T23:59:59Z" test="less_than_or_ 


_equals"/> 


<PredicateBag tYpe="OR"> 




<BinaryPredicate f ieldID="tvaf : ServiceURL" f ieldValue="dvb 


//1.2.1"/> 


<BinarYPredicate fieldID="tvaf: ServiceURL" f ieldValue="dvb 


//1.2.2"/> 


<BinarYPredicate fieldID="tvaf: ServiceURL" f ieldValue="dvb 


//1.2.3"/> 


</PredicateBag> 




</PredicateBag> 





C.8 Searching for programmes with a review 

This query searches for programmes being shown tonight that have a review. This is an example of when an "exists" 
test might be useful. 



<PredicateBag type 


="AND"> 






















<BinarYPredicate 


fieldID= 


="tvaf 


Publish 


edTime 


M 














f ieldValue= 


"2002-09- 


-26T00 


00:00Z" 


test = 


"great 


er_th 


an_ 


_or_ 


equals"/> 


<BinarYPredicate 


fieldID= 


="tvaf 


Publish 


edTime 


II 














f ieldValue= 


"2002-09- 


-27T23 


59:59Z" 


test = 


"less_ 


than_ 


or_ 


_equ 


als"/> 




<UnarYPredicate 


fieldID="tvaf: Review" 


test=" 


exists 


"/> 












</PredicateBag> 

























The query below requests programme reviews of programmes with "Titanic" in the title: 



<QueryConstraints> 

<BinarYPredicate fieldID="tvaf : Title" f ieldValue="Titanic" test="contains"/> 
</QuerYConstraints> 
<RequestedTables> 

< Table tYpe="ProgramReviewTable" /> 
</RequestedTables> 



If we now request for programme reviews of programmes with either "Titanic" or "Star Wars" in the title, it is not clear 
in the result which review corresponds to which part of the request. 



<QuerYConstraints> 

<PredicateBag tYpe="OR"> 

<BinarYPredicate fieldID="tvaf: Title" f ieldValue="Titanic" test="contains"/> 
<BinarYPredicate fieldID="tvaf: Title" f ieldValue="Star Wars" test="contains"/> 
</PredicateBag> 
</QuerYConstraints> 
<RequestedTables> 

< Table tYpe="ProgramReviewTable" /> 
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</RequestedTables> 



A solution to remove the ambiguity is to not use the disjunctive condition in this case and to issue separate requests. 

Another solution to remove the ambiguity is to add the following tables "ProgramlnformationTable" and 
"GroupInformationTable" to the request or to issue a second request for "ProgramlnformationTable" and 
"GroupInformationTable" using CRIDs returned within the first response. 



C.9 Updating a fragment 



The following query will check to see if a metadata service has a later version of a fragment than the version cached by 
the receiver. 

<PredicateBag tYpe="AND"> 

<Predicate f ieldID="tvaf : f ragmentID" f ieldValue="34567"/> 

<Predicate f ieldID="tvaf : fragment Vers ion" 

test="greater_than" f ieldValue="2 002 92 5"/> 
</PredicateBag> 



C.10 Requesting update fragments 

Following is an example of a query to retrieve fragments which are updated after the given date, i.e. September 25, 
2002, using the service described in clause C.5. 

<BinaryPredicate f ieldID="tvaf : fragment Vers ion" test=" great er_than" 
fieldValue="2 002 92 5"/> 

As a response to the previous example query, a metadata of following format can be received. In this response, it 
notifies the client system that the fragment with fragmentID "11" published before September, 30, 2002 and the 
fragment with fragmentID "15" published before September, 27, 2002 are no longer valid in addition to the updated 
fragments of programme information table and programme location table. 

<get_Data_Result . . .> 
<Invalid> 

<Fragment f ragmentID="ll" f ragmentVersion="20020930"/> 
<Fragment f ragmentID="15" f ragmentVersion="20020927"/> 
</Invalid> 

<TVAMain version="20020928" publisher="TVA-Metadata-Service" ...> 
<ProgramDescription> 

<P rogramin format ionTable> 

<ProgramIn format ion f ragmentID=" 04 " fragmentVersion=" 2002 1001 "> 

<! — . . : etc. — > 
</ProgramInf ormation> 
</ProgramInf ormationTable> 
<ProgramLocationTable> 

<Schedule f ragmentID="023" f ragmentVersion="20020928"> 

</Schedule> 
</ProgramLocationTable> 
</ProgramDescription> 
</TVAMain> 
</get_Data_Result> 
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Annex D (informative): 

Examples of get_Data Operation's Capability Description 

This annex gives some examples of the different types of functionahty a get_Data operation might offer in real-life 
TV-Anytime metadata service deployments. 

D.1 Pure location resolution service 

A broadcaster provides a location resolution service over IP as an alternative to its unidirectional location resolution 
service. No other data is provided by the web service, which only offers a get_Data operation that is capable of 
returning a ContentRef erencingTable and no other table types. Only CRIDs from the autnam.com authority 
can be resolved using this operation. 

<describe_get_Data_Result serviceVersion="3 " 
xmlns="urn : tva : transport : 2002 "> 
<AvailableTables> 

< Table xsi : t ype=" ContentRef erencingTable "> 
<ResolvingAuthorityRecordTable 

xmlns="urn : tva : ResolvingAuthority : 2002 "> 
<ResolvingAuthorityRecord> 

<ResolutionProvider>autnam. com</ResolutionProvider> 
<AuthorityName>autnam. com</AuthorityName> 
<Class>primary</Class> 
<VersionNumber>1000</VersionNumber> 
<URL>http : //www . autnam. com/lr/</URL> 

<FirstValidDate>2000-0 9-0 6T0 9:30:00Z</FirstValidDate> 
<LastValidDate>2 000-0 9-2 8T18 : 00 : OOZ</LastValidDate> 
<Weighting>l</Weighting> 
</ResolvingAuthorityRecord> 
</ResolvingAuthoritYRecordTable> 
</Table> 
</AvailableTables> 
</describe_get_Data_Result> 



D.2 Pure metadata retrieval service for broadcast 
enhancement 

A broadcaster chooses to deliver enhanced metadata (critical reviews and segmentation data) using the bi-directional 
channel. All other data (including scheduling and content referencing information) is delivered by means of the 
unidirectional channel. The broadcaster offers a get_Data operation that is able to provide a 

Programlnf ormationTable, Grouplnf ormationTable, ProgramReviewTable and 
Segmentlnf ormationTable in its responses. All of these tables can be queried using the fragmentld and 
f ragmentVersion to allow integration with, and updating of, unidirectionally delivered metadata. This is indicated 
using the UpdateCapability element appropriately. In addition, the Programlnf ormationTable and 
Grouplnf ormationTable can be sorted according to Title and Genre fields. Queries based upon metadata 
constraints are not supported by this metadata service. 

<describe_get_Data_Result serviceVersion="3" 
xmlns="urn : tva :transport:2002"> 
<AuthorityList> 

<AuthoritY>broadcaster . com< /Author it y> 
< /Author it yLi St > 
<AvailableTables 

xmlns : tvaf ="urn : tva : transport :fieldIDs:2002"> 
< Table xsi : type="ProgramInf ormationTable" canQuery="tvaf : fragment ID 
tvaf : f ragmentVersion" canSort="tvaf : Title tvaf : Genre"/> 
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<Table xsi : type="GroupInf ormationTable" canQuery="tvaf : f ragmentID 

tvaf : f ragmentVersion" canSort="tvaf: Title tvaf : Genre"/> 
< Table xsi : tYpe="ProgramReviewTable" canQuerY="tvaf : f ragmentID 

tvaf : f ragmentVersion" /> 
< Table xsi : t ype=" Segment In f ormationTable" canQuery="tvaf : fragment ID 
tvaf : f ragmentVersion" /> 
</AvailableTables> 

<UpdateCapability versionRequest="true" invalidResponse=" false" /> 
</describe_get_Data_Result> 



D.3 A rich metadata service that allows users to search 
for movies 

The operation could be provided by a third party (e.g. IMDB.com) who creates its own CRIDs that can be resolved into 
creator CRIDs. This would require the web server to provide a get_Data operation that supports searches for movies 
based on Title, Keywords, Genre and Actors / Directors. The operation also allows searches on an extended field: 
colour. The operation is able to return a ContentRef erencingTable, Programlnf ormationTable and 
ProgramReviewTable. 

<describe_get_Data_Result serviceVersion="3 " 
xmlns="urn : tva :transport:2002"> 
<Name>Barry Norman's Movie Recommendations</Name> 

<Description>For dedicated movie fans. Find the latest reviews and 
ratings</Description> 
<ExtendedFieldList 

tar get Name spa ce=http : //www . barry-norman . com/ tva- fields 
xmlns : tva="urn : tva : metadata : 2 002 "> 
<FieldIDDefinition fieldID= "Color " 
f ieldDef inition=" /tva : TVAMain/tva : ProgramDe script ion /tva : Programlnf ormationTable /tva : Prog 
r ami n format ion /tva : AVAttributes/tva : VideoAttributes/tva : Color/ @type" /> 
</ExtendedFieldList> 
<AuthorityList> 

<Authority>barry-norman . com</Authority> 
</AuthorityList> 
<AvailableTables> 

< Table xsi : t ype=" ContentRef erencingTable "> 
<ResolvingAuthorityRecordTable 

xmlns="urn : tva : ResolvingAuthority : 2 002 "> 
<ResolvingAuthorityRecord> 

<ResolutionProvider>barry-norman . com</ResolutionProvider> 
<AuthorityName>barry-norman . com</AuthorityName> 
<Class>primary</Class> 
<VersionNumber>1000</VersionNumber> 
<URL>http : //www . barry-norman . com/tva</URL> 
<FirstValidDate>2000-0 9-0 6T0 9:30:00Z</FirstValidDate> 
<LastValidDate>2 000-0 9-2 8T18 : 00 : OOZ</LastValidDate> 
<Weighting>l</Weighting> 
</ResolvingAuthorityRecord> 
</ResolvingAuthorityRecordTable> 
</Table> 
< Table xsi : type="ProgramInf ormationTable" 

xmlns : tvaf =urn : tva : transport :fieldIDs: 2002 
xmlns : ef =http : //www . barry-norman . com/ tva- fields 
canQuery="tvaf : Title tvaf :Keyword tvaf :Genre tvaf :Role 
tvaf : GivenName tvaf :FamilyName ef : Color" /> 
< Table xsi : type="ProgramReviewTable" /> 
</AvailableTables> 
</describe_get_Data_Result> 



£75/ 



54 ETSI TS 1 02 822-6-1 V1 .1 .1 (2003-1 0) 



D.4 Broadcaster provided metadata service used for 
constructing traditional EPGs 

The metadata service allows querying for scheduling information, based upon the start time and content service of the 
programmes. The resulting ProgramLocationTable can be sorted according to the start time and channel of the 
programmes. Using the associated Programinf ormationTable a receiver can efficiently construct an EPG. 

<describe_get_Data_Result serviceVersion="3 " 
xmlns="urn : tva :transport:2002"> 
<AuthorityList> 

<Authority>broadcaster . com</AuthoritY> 
</AuthorityList> 
<AvailableTables 

xmlns : tvaf ="urn : tva :transport:fieldIDs:2002"> 
< Table xsi : type="Progr ami nf ormationTable" /> 
< Table xsi : type="ProgramLocationTable" canQuery="tvaf : ServiceURL 

tvaf :PublishedTime" canSort=" tvaf : ServiceURL tvaf :PublishedTime"> 
<AvailableLocations> 

<Availability>P7D</Availability> 
<ServiceURL>dvb: 112 . 7dl . 13</ServiceURL> 
<ServiceURL>dvb: 112 . 7dl . 14</ServiceURL> 
</AvailableLocations> 
</Table> 
</AvailableTables> 
</describe_get_Data_Result> 



D.5 Pure metadata retrieval service for bi-directional 
channel 

A third party or a broadcaster could deliver metadata using the bi-directional channel. The third party or the broadcaster 
offers a get_Data operation that is able to provide a Programinf ormationTable, 
Grouplnf ormationTable, ProgramReviewTable ProgramLocationTable, and 
Segment Informat ionTable in its responses. The metadata service allows querying for scheduling information, 
based upon the start time, end time. The resulting ProgramLocationTable can be sorted according to the start 
time and channel of the programmes. All of these tables can be queried using the f ragmentld and 
f ragmentVersion to allow updating of the previously delivered metadata. This is indicated using the 
UpdateCapability element appropriately. 

<describe_get_Data_Result serviceVersion="3" 
xmlns="urn : tva : transport : 2002 "> 
<AuthorityList> 

<Authority>broadcaster . com</Authority> 
</AuthorityList> 
<AvailableTables 

xmlns : tvaf ="urn : tva :transport:fieldIDs:2002"> 
< Table xsi : type="ProgramInf ormationTable" 

canQuery="tvaf : fragment ID tvaf : f ragmentVersion" 
canSort="tvaf: Title tvaf : Genre" /> 
< Table xsi : type=" Grouplnf ormationTable" 

canQuery="tvaf : f ragmentID tvaf : f ragmentVersion" 
canSort="tvaf: Title tvaf : Genre" /> 
< Table xsi : type="ProgramReviewTable" 

canQuery="tvaf : fragment ID tvaf : f ragmentVersion" /> 
< Table xsi : t ype=" Segment In f ormationTable" 

canQuery="tvaf : fragment ID tvaf : f ragmentVersion" /> 
< Table xsi : type="ProgramLocat ionTable" 

canQuery=" tvaf : f ragmentID tvaf : f ragmentVersion tvaf :PublishedTime" 
canSort="tvaf : ServiceURL tvaf : PublishedTime"> 
<AvailableLocations> 

<Availability>P7D</Availability> 
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<ServiceURL>dvb: //2 . 7dl . 13</ServiceURL> 
<ServiceURL>dvb: 112 . 7dl . 14</ServiceURL> 
</AvailableLocations> 
</Table> 
</AvailableTables> 

<UpdateCapabilitY versionRequest="true" invalidResponse="true" /> 
</describe_get_Data_Result> 
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Annex E (informative): 

Use of BilVI Encoded IVIetadata in Bi-directional Transport 

This clause provides a framework for the OPTIONAL usage of BiM encoding of SOAP, within the context of 
TV-Anytime delivery of metadata over a bi-directional network. It ensures encodability of SOAP messages and 
interoperability between applications within that context. 



E.1 Applying BiM encoding 



In order to apply BiM encoding to a SOAP message, one needs to have an XML Schema describing it. Given the 
constraints expressed in the present document and the schema it contains, a schema describing a complete SOAP 
message is produced to provide the SOAP specific parts that are missing. Once such a schema is obtained, BiM 
encoding functionality can be added in a non-intrusive manner as it is solely concerned with encoding and Content 
Negotiation (described in clause 6.3). 

Similarly, additional SOAP headers MAY be defined using locally added schema definitions, but will be discarded 
otherwise, taking into account limitations imposed on SOAP listed in clause 6.1. Future versions of the present 
document may define SOAP headers either directly or by reference, in which case they will be added to the schema 
describing the complete SOAP messages. 



E.2 Negotiation of BiM Encoding 

The HTTP 1.0 specification defines a mechanism allowing a user agent to reach an agreement with the server with 
which it is communicating based on the Accept-Encoding and Content-Encoding headers. This process is known as 
Content Negotiation. Clause 6.3 of the present document requires that clients and servers support the Accept-Encoding 
header, and that Content Negotiation take place between them so as to determine the best encoding. 

In addition to this, clients and servers that choose to transfer data in a BiM encoded form SHALL flag BiM encoded 
content with a proper Content-Encoding header upon transmission, and SHALL NOT change the Content-Type 
corresponding to their content. 

The content coding token corresponding to the BiM encoding is x-bim. 
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Annex F (informative): 
Bibliography 

Documents are available from the TV-Anytime web site http://www. TV- Anytime. or:^ . 
"R-1: Call For Contributions" (TV014r3) 
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